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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP). 

The contents of the present document are subject to continuing work within TC SCP and may change following formal 
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with 
an identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

early working draft; 

1 presented to TC SCP for information; 

2 presented to TC SCP for approval; 

3 or greater indicates TC SCP approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

The present document is part 1 of a multi-part deliverable covering the Test specification for the Host Controller 
Interface (HCI), as identified below: 

Part 1 : " Terminal features ' ' ; 

Part 2: "UICC features"; 

Part 3: "Host Controller features". 



Introduction 



The present document defines test cases for the terminal relating to the Host Controller Interface (HCI) as specified in 
TS 102 622 [1]. 

The aim of the present document is to ensure interoperability between the terminal and the UICC independently of the 
respective manufacturer, card issuer or operator. 
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Scope 



The present document covers the minimum characteristics which are considered necessary for the terminal in order to 
provide compliance to TS 102 622 [1]. 

The present document specifies the test cases for: 

• the HCI core as described in the first part of TS 102 622 [1]; 

• the contactless platform as described in the second part of TS 102 622 [1]. 

Test cases for the UICC relating to TS 102 622 [1] and test cases for the Single Wire Protocol (SWP) covering both 
terminal and UICC are out of scope of the present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

• In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version 
of that document in the same Release as the present document. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 622: "Smart Cards; UICC - Contactless Front-end (CLF) Interface; Host Controller 

Interface (HCI)". 

[2] ETSI TS 102 613: "Smart Cards; UICC - Contactless Front-end (CLF) Interface; Part 1: Physical 

and data link layer characteristics". 

[3] ETSI TS 102 223: "Smart Cards; Card AppHcation Toolkit (CAT)". 

[4] ISO/lEC 18092: "Information technology - Telecommunications and information exchange 

between systems - Near Field Communication - Interface and Protocol (NFCIP-1)". 

[5] ISO/IEC 14443-2: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 2: Radio frequency power and signal interface". 

[6] ISO/IEC 14443-3: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 3: Initiahzation and anticolhsion" . 

[7] ISO/IEC 14443-4: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 4: Transmission Protocol". 

[8] ISO/IEC 7816-4: "Information technology - Identification cards - Integrated circuit(s) cards with 

contacts - Part 4: Interindustry commands for interchange". 

[9] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 
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[10] ETSI TS 102 695-3: "Smart Cards; Test specification for the Host Controller Interface (HCI) 

Part 3: Host Controller features". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

Not appUcable. 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 622 [1] and the following apply: 

allowed error response code: response code which is not ANY_OK and which is allowed for the referenced command 
as specified in TS 102 622 [1] 

non-occurrence RQ: RQ which has been extracted from TS 102 622 [1], but which indicates a situation which should 
never occur 

NOTE: The consequence is that such RQs cannot be explicitly tested. 

user: describes any logical or physical entity which controls the test equipment in a way that it is able to trigger 
activities of the DUT 

3.2 Symbols 

For the purposes of the present document, the symbols given in TS 102 622 [1] and the following apply: 

PIPEO the static pipe connected to the link management gate of the device under test. 

PlPEl the static pipe connected to the administration gate of the device under test. 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TS 102 622 [1] and the following apply: 

(U)SIM (Universal) Subscriber Identity Module 

AFI Application Family Identifier 

AID Application IDentifier 

ATQA Answer To reQuest of type A 

ATQB Answer To reQuest of type B 

ATS Answer To Select 

CLF ContactLess Front-end 

CLT ContactLess Tunnelling 

DUT Device under test 

FES For further study 

HCI Host Controller Interface 

HCUT Host controller under test 

HS Host simulator 

ICRx Initial condition requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 

NAA Network Access Application 

PCD Proximity Coupling Device 

PICC Proximity Integrated Circuit Card 
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PPS 

RATS 

REQA 

RF 

RO 

RQ 

RW 

SAK 

SRx 



Protocol and Parameter Selection 

Request for Answer To Select 

REQuest command, type A 

Radio Frequency 

Read-Only 

Conformance requirement 

Read-Write 

Select AcKnowledge 

Static requirement (where x is a number) 



NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 

TC Test Case 

TRx Trigger requirement (where x is a number) 

UID Unique IDentification 

WUPB Wake-Up command for PICC type B 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 



3.4 



Formats 



3.4.1 Format of the table of optional features 

The columns in table 4. 1 have the following meaning. 



Column 


Meaning 


Option 


The optional feature supported or not by the DUT. 


Status 


See clause 3.4.3. 


Support 


The support columns shall be filled in by the supplier of the implementation. The following common 
notations, defined in ISO/IEC 9646-7 [9], are used for the support column in table 4.1 . 
Y or y supported by the implementation. 
N or n not supported by the implementation. 

N/A, n/a or - no answer required (allowed only if the status is N/A, directly or after evaluation of a 
conditional status). 


IVInemonic 


The mnemonic column contains mnemonic identifiers for each item. 



3.4.2 Format of the applicability table 

The applicability of every test in table 4.2 is formally expressed by the use of Boolean expression defined in the 
following clause. 

The columns in table 4.2 have the following meaning. 



Column 


Meaning 


Clause 


The "Clause" column identifies the clause containing the test case referenced in the "Test case number 
and description" column. 


Test case 
number and 
description 


The "Test case number and description" column gives a reference to the test case number (along with 
the corresponding description) detailed in the present document and required to validate the DUT. 


Release 


The "Release" column gives the Release applicable and onwards, for the corresponding test case. 


Execution 
requirements 


The usage of the "Execution requirements" column is described in clause 4.5.2. 


Rel-x Terminal 


For a given Release, the corresponding "Rel-x " column lists the tests required for a DUT to be declared 
compliant to this Release. 


Support 


The "Support" column is blank in the proforma, and shall be completed by the manufacturer in respect of 
each particular requirement to indicate the choices, which have been made in the implementation. 
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3.4.3 Status and Notations 

The "Rel-x" columns show the status of the entries as follows: 

The following notations, defined in ISO/IEC 9646-7 [9], are used for the status column: 



mandatory - the capability is required to be supported. 

optional - the capability may be supported or not. 

not applicable - in the given context, it is impossible to use the capability. 

prohibited (excluded) - there is a requirement not to use this capability in the given context. 

qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which 
identifies an unique group of related optional items and the logic of their selection which is 
defined immediately following the table. 

conditional - the requirement on the capability ("M", "O", "X" or "N/A") depends on the support 
of other optional or conditional items, "i" is an integer identifying an unique conditional status 
expression which is defined immediately following the table. For nested conditional expressions, 
the syntax "IF ... THEN (IF ... THEN ... ELSE...) ELSE ..." shall be used to avoid ambiguities. 

References to items 

For each possible item answer (answer in the support column) there exists a unique reference, used, for example, in the 
conditional expressions. It is defined as the table identifier, followed by a solidus character "/", followed by the item 
number in the table. If there is more than one support column in a table, the columns shall be discriminated by letters 
(a, b, etc.), respectively. 



M 
O 

N/A 

X 

O.i 

Ci 



EXAMPLE: 



4. 1/4 is the reference to the answer of item 4 in table 4. 1 . 



4 Test environment 

4.1 Table of optional features 

The device supplier shall state the support of possible options in table 4.1. See clause 3.4 for the format of table 4.1. 

Table 4.1 : Options 



Item 


Option 


Status 


Support 


Mnemonic 


1 


Data link layer specified in TS 102 613 [2] is used 







102 613 
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4.2 Applicability table 



Table 4.2 specifies the applicability of each test case to the device under test. See clause 3.4 for the format of table 4.2. 

Clause 4.5.2 should be referenced for usage of the execution requirements which are referenced in table 4.2 a) and described in table 4.2 c). 

Table 4.2 a): Applicability of tests 



Clause 


Test case number and description 


Release 


Execution 
requirements 


Rel-7 
Terminal 


Rel-8 
Terminal 


Support 


5.1.3.2 


Test case 1 : existence of gates 


Rel-7 




M 


M 




5.1.4.2 


Test case 1 : static pipe deletion 


Rel-7 




M 


M 




5.1.4.3 


Test case 2: initial pipe state and persistence of pipe state and registry value 


Rel-7 


TR1 


M 


M 




5.1.5.2 


Test case 1 : registry deletion 


Rel-7 


SRI 


M 


M 




5.2.2.2 


Test case 1 : commands/events on pipe which is not open 


Rel-7 




M 


M 




5.3.1.2.3.2 


Test case 1 : ANY OPEN PIPE reception 


Rel-7 




M 


M 




5.3.1.2.4.2 


Test case 1 : ANY CLOSE PIPE reception 


Rel-7 




M 


M 




5.3.2.2 


Test case 1 : response to unknown command 


Rel-7 




M 


M 




5.3.3.2 


Test case 1 : reception of unknown events 


Rel-7 




M 


M 




5.4.2.1.1.2 


Test case 1 : SESSION IDENTITY 


Rel-7 




M 


M 




5.4.2.1.1.3 


Test case 2: MAX PIPE 


Rel-7 




M 


M 




5.4.2.1.1.4 


Test case 3: WHITELIST 


Rel-7 




M 


M 




5.4.2.1.1.5 


Test case 4: HOST LIST 


Rel-7 




M 


M 




5.4.2.3.1.2 


Test case 1 : registry parameters 


Rel-7 




M 


M 




5.5.1.2.2 


Test case 1 : valid pipe deletion from host to host controller 


Rel-7 




M 


M 




5.5.1.3.2 


Test case 1 : identity reference data when TS 1 02 61 3 [2] is used 


Rel-7 




C101 


C101 




5.5.1.3.3 


Test case 2: reception of ADIVI CLEAR ALL PIPE - static pipes, dynamic pipes to host 


Rel-7 




M 


M 




5.5.4.2 


Test case 1 : inhibited state 


Rel-7 




M 


M 




5.5.4.3 


Test case 2: inhibited state, followed by subsequent successful identity check 


Rel-7 




M 


M 




5.5.5.2 


Test case 1 : processing of EVT POST DATA 


Rel-7 




M 


M 




5.6.1.2 


Test case 1 : RF gate of type A 


Rel-7 




M 


M 




5.6.1.3 


Test case 2: RF gate of type B 


Rel-7 




M 


M 




5.6.3.3.4.2.2 


Test case 1 : UID REG - default 


Rel-7 




M 


M 




5.6.3.3.4.2.3 


Test case 2: SAK 


Rel-7 




M 


M 




5.6.3.3.4.2.4 


Test case 3: ATS - default parameters 


Rel-7 




M 


M 




5.6.3.3.4.2.5 


Test case 4: APPLICATION DATA 


Rel-7 




M 


M 




5.6.3.3.4.2.6 


Test case 5: DATARATE MAX 


Rel-7 




M 


M 




5.6.3.3.4.3.2 


Test case 1 : PUPI REG - default 


Rel-7 




M 


M 




5.6.3.3.4.3.3 


Test case 2: ATOB - verify the different parameter 


Rel-7 




M 


M 




5.6.3.3.4.3.4 


Test case 3: HIGHER LAYER RESPONSE 


Rel-7 




M 


M 




5.6.4.1.2 


Test case 1 : ISO/IEC 14443-3 [6] Type A - Full Power Mode 


Rel-7 




M 


M 




5.6.4.1.3 


Test case 2: ISO/IEC 14443-3 [6] Type B 


Rel-7 




M 


M 
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Conditional item 


Condition 


Description 


C101 


IF 4.1/1 THEN M ELSE N/A 


102 613 



Table 4.2 c): Execution requirements referenced by table 4.2 a) 



Execution requirement 



Description 



SRI 



A gate which accepts dynamic pipe and has a RW registry parameter; the default value of the registry parameter must be known. 



TR1 



The PUT manufacturer has to provide information how the host controller can be powered down and powered up. 



NOTE: Clause 4.5.2 should be referenced for the meaning and usage of the execution requirements which are described in table 4.2 c). 
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4.3 Information to be provided by the device supplier 

The device supplier shall provide the information indicated in table 4.3. 

Table 4.3: Default configuration 



Item 


Description 


Presence/Value 


Status 


Mnemonic 


1 


Indication of presence of VERSION SW, and value if supported. 




M 


V VERSION SW 


2 


Indication of presence of VERSION HARD, and value if supported. 




M 


V VERSION HARD 


3 


Indication of presence of VENDOR NAIVIE, and value if supported. 




M 


V VENDOR NAME 


4 


Indication of presence of IVIODEL ID, and value if supported. 




M 


V MODEL ID 


5 


Indication of presence of HCI VERSION, and value if supported. 




M 


V HCI VERSION 


6 


Value of GATES LIST 




M 


V GATES LIST 


7 


Value of MAX PIPE. 




M 


V MAX PIPE 


8 


Value of HOST LIST 




M 


V HOST LIST 


NOTE: Conditional values shall be provided if the corresponding option is supported in the table 4.1 . 



4.4 Test equipment 



The test equipment shall provide a host simulator which is connected to the DUT during test procedure execution, 
unless otherwise specified. 

With respect to the DUT, the host simulator shall act as a valid host according to TS 102 622 [1] unless otherwise 
specified. In particular, the host simulator shall ensure that the value GATES_LIST is valid, according to the particular 
requirements of the test case being executed. 

With respect to the DUT, the host simulator shall comprise a valid host according to the specific DUT. The details are 
out of the scope of the present document. 

For some test cases, usage of a PCD is required. The detailed requirements are specified in the individual test cases. 

The test equipment shall ensure that a matching SYNC_ID is used during test case execution, unless otherwise 
specified. 

Some terminals might require the presence of an NAA (e.g. (U)SIM), which shall be provided by the test equipment. 

NOTE: The implementation of the terminal may imply certain activities or settings on the HCI layer. This should 
be taken into account when testing the HCI interface (e.g. PIPE state should be checked, activity after 
initialization, already open pipes, etc.). 

With respect to the DUT, the host simulator shall act as a valid host according to TS 102 622 [1] unless otherwise 
specified. In particular, the host simulator shall ensure before running a test case that all static pipes are closed, all 
dynamic pipes are deleted and the registry values are set to their defaults by running the sequence in table 4.4. 

Table 4.4: HCI test case initialization sequence 



Step 


Direction 


Description 


a1 


HS^ HCUT 


Send ANY OPEN PIPEonPIPEL 


a2 


HCUT^ HS 


Send ANY OK. 


a3 


HS-> HCUT 


Send ADM CLEAR ALL PIPE on PIPE1 with parameter ('FF FF'). 


a4 


HCUT^ HS 


Send ANY OK. 



Before the execution of the RF technology test cases, RF gate parameters has to be modified properly to run the test. 

4.4.1 Measurement / setting uncertainties 

Void. 
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4.4.2 Default conditions for DUT operation 

Unless otherwise specified, the test equipment shall apply the default conditions described in the following clauses 
during test procedure execution. 

4.4.2.1 General 

The test equipment shall attempt to ensure that the identity check mechanism of the lower layer passes (see 
TS 102 622 [1], clause 8.4). 

If the test procedure indicates that the host simulator is to send ANY_OK in response to an ANY_OPEN_PIPE 
command, the parameter shall contain the number of pipes already open on the gate before the execution of the 
command. 

4.4.2.2 Status of UICC interfaces 

Void. 

4.4.3 Minimum/maximum conditions for DUT operation 

Void. 

4.4.4 Conventions 

Unless otherwise specified, ADM_CREATE_PIPE is sent by the test equipment with source Hid = Hid of host simulator 
and destination Hid = Hid of host controller. 

If the pipe for a response is not explicitly specified, then the pipe for the response is required to be the pipe on which the 
preceding command was sent. 

4.5 Test execution 

4.5.1 Parameter variations 

Unless otherwise specified, all test cases shall be carried out in full power mode only, and for the parameter variations 
specified individually for each test case. 

4.5.2 Execution requirements 

Table 4.2, Applicability of tests, specifies "execution requirements" for several test cases. For these test cases, it has not 
been possible to specify the corresponding test procedure in such a way that it can be guaranteed that the test procedure 
can be executed against every possible DUT. 

Some sample scenarios of test requirements are listed below: 

• The test case requires certain state to be present on the DUT in order to test a particular feature, but there is no 
mandatory requirement in the core specification (TS 102 622 [1]) for this state to be present. 

• The test case requires the DUT to perform a particular operation in order to test that feature, but the core 
specification (TS 102 622 [1]) does not provide a standardized mechanism to trigger that operation to be 
executed by the DUT. 

The test requirements have been split into various categories, as indicated by table 4.2 c): 

• Static requirements (SRx): information about, for example, particular gates or registry parameters which can 
be used in the test procedure execution. 

• Trigger requirements (TRx): mechanisms for triggering the DUT to perform certain operations. 
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• Initial condition requirements (ICRx): information about how to establish initial condition states. 

The DUT supplier should make every effort to provide appropriate information or mechanisms to allow these execution 
requirements to be satisfied for the DUT. 

It is recognized that this might not always be possible. For example, if the configuration of the DUT does not allow for 
the required state to be present; or if it is not possible to provide a particular trigger mechanism for the DUT. In these 
cases, it is acceptable that the test case is not carried out. However, it should be recognized that the consequence is that 
the particular feature will not be tested. 

4.6 Pass criterion 

A test shall only be considered as successful, if the test procedure was carried out successfully under all parameter 
variations with the DUT respecting all conformance requirements referenced in the test procedure. This is subject to the 
additional qualifications described in clause 4.6.1. 

NOTE: Within the test procedures, the RQs are referenced in the step where they are observable. In some cases, 
this is different from the step where they occur with respect to the DUT. 

4.6.1 Unanticipated beinaviour from tine DUT 

In the specification of the test procedures, every attempt has been made to ensure that the interface between the 
simulator and the DUT is in a known state before and during test procedure execution. However, as the DUT is an 
autonomous device, it is not possible to fully guarantee this. 

If the DUT unexpectedly closes or deletes a pipe which is intended to be used during a subsequent part of the test 
procedure, this should not be considered as a failure of the DUT, even though the test procedure cannot be completed 
successfully. Instead, the test procedure should be executed again to attempt to execute the test procedure to 
completion. If the unexpected behaviour occurs again, further effort should be applied by the tester to attempt to ensure 
that the unexpected behaviour does not occur. 



5 Test cases 

5.1 HCI arclnitecture 

5.1.1 Overview 

Reference: TS 102 622 [1], clause 4.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.1.2 Hosts 

Reference: TS 102 622 [1], clause 4.2. 



RQ4.1 The host controller shall not use host identifiers which are RFU. 



RQ4.2 [The host controller shall reject received host identifiers which are RFU. 



NOTE 1 : RQ4.1 is a non-occurrence RQ. 

NOTE 2: Development of test cases for RQ4.2 is FFS. 
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5.1.3 Gates 

5.1.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.3. 



RQ4.3 



The host controller shall have one administration gate. 



RQ4.4 



The host controller shall have one link management gate. 



RQ4.5 



The host controller shall have one identity management gate. 



RQ4.6 



The host controller shall have one loop back gate. 



RQ4.7 



The host controller shall not use gate identifiers which are RFU. 



RQ4.8 



Void 



RQ4.9 



The host controller shall not use gate identifiers which are host specific but not yet allocated in TS 102 622 [1] 



RQ4.10 



Void 



NOTE: RQ4.7 and RQ4.9 are not tested, as they are non-occurrence RQs. 



5.1 .3.2 Test case 1 : existence of gates 

5.1.3.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.1.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEO is open. 

• PlPEl is open. 

5.1 .3.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ANY GET PARAMETER(REC ERROR) on PIPEO. 




2 


HCUT^HS 


Send ANY OK (parameters are not checked). 


RQ4.4 


3 


HS ^ HCUT 


Send ADI\/I_CREATE_PIPE on PIPE1, with source and destination 
GiD = GiD of identity management gate. 




4 


HCUT^HS 


Send ANY OK (parameters are not checked); designate the created pipe 
PIPE ID MAN. 


R04.3, 
RQ4.5 


5 


HS ^ HCUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




6 


HCUT^HS 


Send ANY OK. 


RQ4.5 


7 


HS ^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




8 


HCUT ^ HS 


Send ANY_OK. 

Check that the GATES_LIST returned contains the Gid of the identity 

management gate and the Gid of the loop back gate. 


R04.5, 
RQ4.6 



5.1.3.3 



Void 



5.1.4 Pipes 



5.1.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.4. 



R04.11 



The host controller shall not attempt to delete a static pipe. 



R04.12 



The host controller shall reject any attempts to delete a static pipe. 



R04.13 



The state of a pipe (i.e. open or closed) shall remain persistent if the hosts are powered down and up 
again. 



R04.14 



The state of a dynamic pipe after creation shall be closed. 
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RQ4.15 



The initial state of a static pipe shall be closed. 



RQ4.16 



The host controller shall not use pipe identifiers which are RFU. 



RQ4.17 



The state of a pipe shall remain persistent if a host is temporarily removed from the host network and 
was not replaced by a different device in the meantime. 



RQ4.18 



For dynamic pipes, pipe identifiers are dynamically allocated by the host controller. 



RQ4.19 



All pipe identifiers allocated by the host controller for dynamic pipes shall be in the range '02' to '6F'. 
Dynamic pipe identifiers shall be unique in the host network. 



RQ4.20 



NOTE 1 
NOTE 2 
NOTES 

NOTE 4: 



RQ4.1 1 and RQ4.16 are not tested, as they are non-occurrence RQs. 

RQ4.15 is not tested, as it is not clear when the initial state of the static pipe applies. 

RQ4.18 is covered in clause 8.1.1 of TS 102 622 [1], covered by clause 5.5.1.1 of the present 

document. This RQ is therefore not tested within this clause, as it is effectively tested in clause 5.5.1 .1 . 

RQ4.19 and RQ4.20 are tested implicitly in different test cases in this test specification. 



Reference: TS 102 622 [1], clauses 7.1.1.1. 



|RQ7.2 [The registry of the host controller administration gate shall be persistent. 



Reference: TS 102 622 [1], clauses 8.1.1, 6.1.3.1 and 6.1.3.2. 



R08.3 



The host controller assigns an unused pipe identifier. 



RO6.30 



When the pipe was successfully created, the host controller shall send the response ANY_OK in 
response to the ADIVI_CREATE_PIPE command, with parameters as specified in TS 102 622 [1]. 



R08.7 



When a pipe is created towards the host controller then only steps 1 and 4 in figure 6 of TS 102 622 [1] 
are needed. 



5.1 .4.2 Test case 1 : static pipe deletion 

5.1.4.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• PIPEO. 

• PIPEl. 

5.1.4.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEl is open. 

5.1 .4.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ADM_DELETE_PIPE containing the pipe indicated in the test execution 
clause, on PIPEl. 




2 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ4.12 



5.1.4.3 



Test case 2: initial pipe state and persistence of pipe state and registry value 



5.1 .4.3.1 Test execution 

There are no test case-specific parameters for this test case. 
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5.1.4.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 

• The value of SESSIONJDENTITY in the registry is not 'FFFFFFFFFFFFFFFF'. 



5.1.4.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ADM_CREATE_PIPE on PIPEl , with source Gid = 'EE' and 
destination Gid = Gid of the loop back gate. 




2 


HCUT-^HS 


Send ANY OK (parameters are not checked); designate the created pipe 
PIPE LOOP BACK. 




3 


HS ^ HCUT 


Open PIPE on PIPE LOOP BACK. 




4 


HCUT -» HS 


Send ANY OK. 




5 


HS ^ HCUT 


Send ADI\/I_CREATE_PIPE on PIPEl , with source Gid = '00' and 
destination Gid = Gid of identity management gate. 




6 


HCUT -^ HS 


Send ANY_OK, with parameters of 5 bytes as follows: 

• Source Hid = Hid of host simulator. 

• Source Gid = source Gid in command. 

• Destination Hid = destination Hid in command. 

• Destination Gid = destination Gid in command. 

• Pid = a previously unallocated Pid. 
Designate the create pipe PIPE ID MAN. 


RQ4.14, 
RQ4.18, 
R07.2 
R08.3. 
RQ6.30, 
R08.7 


7 


HS ^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on (PIPE ID MAN). 




8 


HCUT ^ HS 


Send response containing an allowed error response code for the 
command. 


R04.14 


9 


User^ 
HCUT 


Trigger both the host controller and the host simulator to be powered 
down. 




10 


HCUT-^HS 


Power down the host simulator. 




11 


HCUT 


Powered down. 




12 


User-» 
HCUT 


Trigger both the host controller and the host simulator to be powered up. 




13 


HCUT 


Powered up. 




14 


HCUT-^HS 


Power up the host simulator. 




15 


HS ^ HCUT 


Send ANY GET PARAMETER (SESSION IDENTITY) on PIPEl. 




16 


HCUT^HS 


Send ANY_OK, with parameter value equal to the parameter value before 
the terminal was powered down. 


R07.2 


17 


HS -> HCUT 


Send ANY CLOSE PIPE on PIPEl. 




18 


HCUT-^HS 


Send ANY OK. 


R04.13 


19 


HS -^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




20 


HCUT->HS 


Send response containing an allowed error response code for the 
command. 


R04.13 


21 


HS -> HCUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




22 


HCUT-^HS 


Send ANY OK. 


R04.13 


23 


HS ^ HCUT 


Send EVT POST DATA on PIPE LOOP BACK. 




24 


HCUT ^ HS 


SendEVT POST DATA on PIPE LOOP BACK. 


RQ4.13 



5.1.5 Registries 



5.1.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.5. 



For all gates defined in TS 102 622 [1], parameter identifiers in the range of 'GO' to 'EF' are reserved for 
use in TS 102 622 [1]. 



RQ4.21 



RQ4.22 



A new instance of the registry is created for every pipe that connects to the gate. 



RQ4.23 



Upon pipe creation all registry parameters with access rights Read-write (RW) or Write-only (WO) shall 
be set to their default values. 



RQ4.24 



Upon pipe creation all read-only (RO) parameters shall be set by the entity managing the registry to an 
appropriate value which may differ from the default values. 
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RQ4.25 When a pipe is deleted its registry instance is also deleted. 



RQ4.26 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 102 622 [1] 
shall not be present in the registry. 



Ol IClll I IWL XJ^ fjl ^O^l IL III II 1^ I ^^lOll y . 

NOTE 1 : As the specification of registry parameters is specific to each individual registry, RQ4.21 , RQ4.23 and 
RQ4.24 are not tested in this clause, but are tested in other clauses of the present document for each 
individual registry. 

NOTE 2: RQ4.22 is not currently tested as TS 1 02 622 [1] does not specify any gates with the required properties 
to exercise this functionality. 

NOTE 3: Development of test cases for RQ4.26 is FFS. 



5.1.5.2 



Test case 1 : registry deletion 



5.1.5.2.1 



Test execution 



Assignment of terms to entities referenced in SRI: Gid of gate = GATE_X, registry parameter identifier : 
REG_PARAM. 

There are no test case-specific parameters for this test case. 

5.1.5.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 



5.1.5.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS-^ HCUT 


Send ADIVI CREATE PIPE on PIPEl , with source Gid = 'EE' and destination 
Gid = GATE X. 




2 


HCUT-^ HS 


Send ANY OK (parameters are not checked); designate the created pipe 
PIPEa. 




3 


HS ^ HCUT 


Send ANY OPEN PIPE on PIPEa. 




4 


HCUT^ HS 


Send ANY OK. 




5 


HS ^ HCUT 


Send ANY_SET_PARAMETER(REG_PARAM) on PIPEa, with a value 
different from the default value. 




6 


HCUT^ HS 


Send ANY OK (parameters are not checked). 




7 


HS ^ HCUT 


Send ADM DELETE PIPE(PIPEa) on PIPEL 




8 


HCUT-^ HS 


Send ANY OK (parameters are not checked). 




9 


HS ^ HCUT 


Send ADM CREATE PIPE on PIPEl , with Gid = GATE X. 




10 


HCUT^ HS 


Send ANY OK (parameters are not checked); designate the created pipe 

PIPEb. 

(The PiD used for PIPEb may be the same as or may be different from the Pid 

used for PIPEa.) 




11 


HS^ HCUT 


Send ANY OPEN PIPE on PIPEb. 




12 


HCUT^ HS 


Send ANY OK. 




13 


HS^ HCUT 


Send ANY GET PARAMETER(REG PARAM) on PIPEb. 




14 


HCUT ^ HS 


Send ANY OK with parameter value equal to the default value of 
REG PARAM. 


RQ4.25 
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5.2 HCP 

5.2.1 HCP packets 

5.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.1. 



RQ5.1 The host controller shall use the correct structure for transmitted HCP packets. 



RQ5.2 



The host controller shall recognize correctly structured received HCP packets. 



RQ5.3 



When receiving a packet, the host controller as destination host forwards the packet to the destination 
gate. 



RQ5.4 



When it receives a packet from a host, the host controller uses the value of P|q to forward a packet to the 
destination host. 



RQ5.5 



When it receives a packet from a host, the host controller shall verify that the pipe identifier is used by a 
host involved in the creation of the pipe. 



NOTE 1 : RQ5.1 and RQ5.2 are implicitly tested by the testing of higher layers in other clauses of the present 

document. 
NOTE 2: RQ5.3 is internal to the host controller and is not tested in this clause. It will be implicitly tested in many 

other test cases within the current document. 
NOTE 3: RQ5.4 and RQ5.5 are tested in clause 5.5.1.1.2 of the TS 102 695-3 [10]. 



5.2.2 HCP message structure 
5.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.2. 



R05.6 The host controller shall use the correct structure for transmitted HCP messages. 



R05.7 



Type value 3 shall not be used. 



R05.8 



The host controller shall recognize correctly structured received HCP messages. 



R05.9 



A gate shall only accept a command or an event on a pipe when the state of that pipe is open unless 
otherwise stated. 



RO5.10 



A gate shall not send a command or event on a pipe when it is waiting for a response to a previous 
command on that pipe unless otherwise stated. 



NOTE 1 : RQ5.6 and R05.8 are implicitly tested by the testing of higher layers in other clauses of the present 

document. 
NOTE 2: RQ5.7 and RQ5.10 are not tested, as they are non-occurrence ROs. 



5.2.2.2 Test case 1 : commands/events on pipe which is not open 

5.2.2.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.2.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEl is open. 
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5.2.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with source and destination Gid = Gid 
of identity management gate. 




2 


HCUT^ HS 


Send ANY OK (parameters are not cliecl<ed); designate the created pipe 
PIPE ID MAN. 




3 


HS^ HCUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




4 


HCUT^ HS 


Send ANY OK. 




5 


HS ^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




6 


HCUT^ HS 


Send ANY OK (parameters are not checl<ed). 


RQ5.9 


7 


HS ^ HCUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




8 


HCUT-^ HS 


Send ANY OK (parameters are not checl<ed). 




9 


HS -^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




10 


HCUT-^ HS 


Send response containing an allowed error response code for the command. 


RQ5.9 


11 


HS ^ HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with source Gid = 'EE' and destination 
Gid = Gid of the loop bacl< gate. 




12 


HCUT^ HS 


Send ANY OK (parameters are not checl<ed); designate the created pipe 
PIPE LOOP BACK. 




13 


HS-^ HCUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




14 


HCUT^ HS 


Send ANY OK. 




15 


HS ^ HCUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




16 


HCUT-^ HS 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 


RQ5.9 


17 


HS ^ HCUT 


Send ANY CLOSE PIPE on PIPE LOOP BACK. 




18 


HCUT^ HS 


Send ANY OK (parameters are not checl<ed). 




19 


HS^ HCUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




20 


HS ^ HCUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




21 


HCUT^ HS 


Send ANY OK. 


RQ5.9 



5.2.3 Message fragmentation 



5.2.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.3. 



R05.11 



Message fragmentation shall be used when the size of the message is larger than supported by the 
underlying data link layer. 



R05.12 



Messages shall be fragmented according to the rules specified in TS 102 622 [1]. 



R05.13 



The destination gate is responsible for rebuilding the message from the fragmented messages. 



R05.14 



If a reset of the underlying data linl< layer occurs, fragments of a partially received message shall be 
discarded and a partially sent message shall be re-sent from the beginning. 



NOTE: Development of test cases for RQ5.11, R05.12, R05.13and RQ5.14isFFS. 
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5.3 



Instructions 



5.3.1 Commands 



5.3.1.1 



Overview 



5.3.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.1. 



RQ6.1 For all gates, the host controller shall not use RFU instruction values ('05' to 'OF') in commands. 



RQ6.2 



For administration gates, the host controller shall not use RFU instruction values ('16' to '3F') in 
commands. 



RQ6.3 



For gates defined in TS 1 02 622 [1 ], the host controller shall not use instruction values between '1 0' and 
'3F' which are not allocated in TS 102 622 [1]. 



NOTE: RQ6.1 , RQ6.2 and RQ6.3 are not tested, as they are non-occurrence RQs. 



5.3.1.2 



Generic commands 



5.3.1.2.1 



ANY SET PARAMETER 



5.3.1 .2.1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.1. 



RQ6.4 


The host controller shall reject an incorrectly formatted ANY_SET_PARAMETER command with an 
allowed error response code. 


RQ6.5 


The host controller shall reject an ANY_SET_PARAIVIETER command if the access right for the 
parameter does not allowed writing (i.e. is not RW or WO). 


RQ6.6 


The host controller shall not send an ANY_SET_PARAMETER command if the access right for the 
parameter does not allow writing (i.e. is not RW or WO). 


RQ6.7 


When the host controller receives a valid ANY_SET_PARAIVIETER command, it shall write the 
parameter value into the registry and respond with ANY OK without any parameters. 


RQ6.8 


Whenever the host controller sends an ANY_SET_PARAMETER command, it shall do so correctly: 

• It shall only be sent to a gate which supports the command. 

• It shall always have at least one byte in the command parameters. 

• The parameter identifier shall match one of those defined for the specific gate. 

• The parameter value shall be a valid value as defined for the specific gate. 


NOTE 1 : RQ6.6 is not tested, as it is a non-occurrence RQ. 

NOTE 2: RQ6.7 and R06.8 are not tested in this clause, as they are effectively tested in other clauses of the 

present document for each individual registry parameter. 
NOTE 3: Test cases for RQ6.5 and RQ6.4 are presented in TS 1 02 695-3 [1 0]. 
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5.3.1.2.2 ANY_GET_PARAMETER 

5.3.1.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.2. 



RQ6.9 



The host controller shall reject an incorrectly formatted ANY_GET_PARAMETER command with an 
allowed error response code. 



RQ6.10 



The host controller shall reject an ANY_GET_PARAMETER command if the access right for the 
parameter does not allowed reading (i.e. is not RW or RO). 



RQ6.11 



The host controller shall not send an ANY_GET_PARAMETER command if the access right for the 
parameter does not allowed reading (i.e. is not RW or RO). 



RQ6.12 



When the host controller receives a valid ANY_GET_PARAMETER command, it shall shall respond with 
ANY_OK with the value of the parameter. 



RQ6.13 



Whenever the host controller sends an ANY_GET_PARAMETER command, it shall do so correctly: 

• It shall only be sent to a gate which supports the command. 

• It shall always have exactly one byte in the command parameters. 

» The parameter identifier shall match one of those defined for the specific gate. 



NOTE 1 : RQ6.1 1 is not tested, as it is a non-occurrence RO. 

NOTE 2: RQ6.12 and RQ6.13 are not tested, as they are effectively tested in other clauses of the present 

document for each individual registry parameter. 
NOTE 3: Test cases for RO6.10 and R06.9 are presented in TS 102 695-3 [10]. 



5.3.1.2.3 ANY_OPEN_PIPE 

5.3.1.2.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.3. 



RQ6.14 The host controller shall reject an incorrectly formatted ANY_OPEN_PIPE command. 



R06.15 



When the host controller receives a valid ANY_OPEN_PIPE command on a closed pipe, it shall open the 
pipe and return ANY_OK without any parameter. 



R06.16 



When the host controller sends an ANY_OPEN_PIPE command, it shall contain no command 
parameters. 



R06.17 



When the host controller receives ANY_OK in response to an ANY_OPEN_PIPE command, it shall open 
the pipe. 



NOTE 1 : In TS 102 622 [1], it is not specified whether ANY_OPEN_PIPE is valid over a pipe which is already 

open. This is therefore not listed as a conformance requirement. 
NOTE 2: Test cases for RQ6.16 and R06.17 are presented in TS 102 695-3 [10], 



5.3.1 .2.3.2 Test case 1 : ANY_OPEN_PIPE reception 

5.3.1.2.3.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.1.2.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 
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Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ANY CLOSE PIPEonPIPEL 




2 


HCUT^ HS 


Send ANY OK. 




3 


HS^ HCUT 


Send ANY OPEN PIPE with parameter '00' on PIPE1 . 




4 


HCUT^ HS 


Send response containing an allowed error response code for the 
command. 


R06.14 


5 


HS ^ HCUT 


Send ANY OPEN PIPEonPIPEL 




6 


HCUT^ HS 


Send ANY OK with no parameters. 


R06.15 


7 


HS^ HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with source and destination 
GiD = GiD of identity management gate. 




8 


HCUT^ HS 


Send ANY OK (parameters are not checked); designate the created pipe 
PIPE ID MAN. 




9 


HS^ HCUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




10 


HCUT^ HS 


Send ANYOK with no parameters. 


R06.15 



5.3.1.2.4 



ANY CLOSE PIPE 



5.3.1.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.4. 



R06.18 


The host controller shall reject an incorrectly formatted ANY CLOSE PIPE command. 


R06.19 


When the host controller receives a valid ANY_CLOSE_PIPE on an open pipe, it shall close the pipe and 
respond with ANY OK and no parameters. 


RO6.20 


When the host controller sends an ANY_CLOSE_PIPE command, it shall contain no command 
parameters. 


R06.21 


When the host controller receives ANY_OK in response to an ANY_CLOSE_PIPE command, it shall 
close the pipe. 


NOTE: Test cases for RQ6.20 and RQ6.21 are presented in TS 1 02 695-3 [10]. 



5.3.1 .2.4.2 Test case 1 : ANY_CLOSE_PIPE reception 

5.3.1.2.4.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.1.2.4.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEl is open. 

5.3.1.2.4.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ANY CLOSE PIPE with parameter '00' on PIPE1. 




2 


HCUT^ HS 


Send response containing an allowed error response code for the 
command. 


R06.18 


3 


HS^ HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with source and destination 
GiD = GiD of identity management gate. 




4 


HCUT^ HS 


Send ANY OK (parameters are not checked); designate the created pipe 
PIPE ID MAN. 




5 


HS^ HCUT 


Send ANY CLOSE PIPEonPIPEL 




6 


HCUT^ HS 


Send ANY OK with no parameters. 


R06.19 


7 


HS^ HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with source and destination 
GiD = GiD of identity management gate. 




8 


HCUT^ HS 


Send response containing an allowed error response code for the 
command. 


R06.19 
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5.3.1.3 



Administration commands 



5.3.1.3.1 



ADM CREATE PIPE 



5.3.1 .3.1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.1. 



RQ6.22 



When the host controller receives an ADM_CREATE_PIPE command, it shall use the WHITELIST 
defined by the destination host in order to verify that the source host is authorized to create a pipe. 



RQ6.23 



When the pipe was successfully created, the host controller shall send the response ANY_OK in 
response to the ADM_CREATE_PIPE command, with parameters as specified in TS 102 622 [1], 



RQ6.42 



When receiving ADM_CREATE_PIPE, the host controller shall accept any gate identifier being 
used as source gate. 



NOTE 1 : All conformance requirements for the referenced clause are included in clauses 5.5.1 .1 and 5.1 .4.3 

of the present document. 
NOTE 2: Development of test cases for RQ6.42 is FFS. 



5.3.1.3.2 



ADM NOTIFY PIPE CREATED 



5.3.1.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.2. 



R06.24 



When the host controller sends an ADM_NOTIFY_PIPE_CREATED command, the command 
parameters shall be 5 bytes long. 



R06.25 



When the host controller sends an ADM_NOTIFY_PIPE_CREATED command as a result of an 
ADM_CREATE_PIPE command being received from a host, the source Hid in the command 
parameters shall be the Hip of that host. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1 .1 of the present 
document. 



5.3.1.3.3 



ADM DELETE PIPE 



5.3.1.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.3. 



RQ6.26 The host that requested the deletion of the pipe can only be the source host or destination host. 



RQ6.27 



When the pipe is successfully deleted, the host controller shall send the response ANYOK without 
parameters. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1 .2 of the present 
document. 



5.3.1.3.4 



ADM NOTIFY PIPE DELETED 



5.3.1.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.4. 



RQ6.28 



When the host controller sends an ADM_NOTIFY_PIPE_DELETED command, the command 
parameters shall be 1 byte long. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1 .2 of the present 
document. 
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5.3.1.3.5 



ADM CLEAR ALL PIPE 



5.3.1.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.5. 



RQ6.29 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command and the data link layer 
specified in TS 102 613 [2] is used, it shall interpret the two bytes in the command parameters as 
the identity reference data, and shall use the identity reference data to initialize the reference data 
used by the host controller to check the UICC host identity. 



RQ6.30 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command, it shall delete all the 
dynamic pipes connected to the requesting host, close all static pipes connected to the requesting 
host and set all registry values related to static pipes connected to the requesting host to their 
default values. 



RQ6.31 



When ADI\/I_CLEAR_ALL_PIPE is successful the host controller shall respond with an ANY_OK 
without parameters. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1 .3 of the present 
document. 



5.3.1.3.6 



ADM NOTIFY ALL PIPE CLEARED 



5.3.1 .3.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.6. 



RQ6.32 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command from a requesting 
host, it shall send ADM_NOTIFY_ALL_PIPE_CLEARED to every host with at least one pipe to the 
requesting host. 



RQ6.33 



When the host controller sends an ADM_NOTIFY_ALL_PIPE_CLEARED command with the host 
controller as the requesting host, it shall delete all dynamic pipes between the host controller and 
the host and shall close all static pipes between the host and the host controller. 



RQ6.34 



When the host controller sends an ADM_NOTIFY_ALL_PIPE_CLEARED command, the command 
parameters shall be one byte long and shall contain the Hip of the requesting host. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1 .3 of the present 
document. 



5.3.2 Responses 



5.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.2. 



RQ6.35 



A response shall be sent to all commands received even to those unknown to the receiving gate. 



RQ6.36 



Responses received out of order (i.e. if no command was sent previously) shall be discarded. 



RQ6.37 



For a received command which is defined in Table 16 in TS 102 622 [1], the host controller shall only 
return a response code which is specified for that command in Table 16 in TS 102 622 [1]. 



NOTE 1 : Development of test cases for R06.37 is FFS. 

NOTE 2: Test cases for R06.36 are presented in TS 1 02 695-3 [1 0]. 



5.3.2.2 Test case 1 : response to unknown command 

5.3.2.2.1 Test execution 

There are no test case-specific parameters for this test case. 
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5.3.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 

5.3.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send command with an RFU instruction value on PIPE1 . 




2 


HCUT^ HS 


Send response (contents are not checl<ed). 


RQ6.35 



5.3.3 Events 

5.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.3. 



RQ6.38 Unl<nown events received sliall be discarded. 



RQ6.39 



EVT_HOT_PLUG shall be sent by the host controller to any other connected host to notify the 
connection or disconnection of a host to the host controller. 



RQ6.40 



When the host controller send EVT_HOT_PLUG, it shall contain no parameters. 



RQ6.41 



For gates defined in TS 102 622 [1], the host controller shall not use event values which are not allocated 
inTS102 622[1]. 



NOTE 1 : RQ6.41 is not tested, as it is a non-occurrence RQ. 
NOTE 2: Development of test cases for RQ6.39 and RQ6.40 is FFS. 



5.3.3.2 Test case 1 : reception of unknown events 

5.3.3.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 

5.3.3.2.3 Test procedure 



step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send event with an RFU instruction value on PIPE ID MAN. 




2 


HS^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




3 


HCUT ^ HS 


Send response with ANY OK and value of GATES LIST. 


RQ6.38 



£75/ 



Release 8 



30 



ETSI TS 102 695-1 V8.0.0 (2011-06) 



5.4 



GATES and subclauses 



5.4.1 GATES 



5.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7. 



RQ7.1 [Gates shall support the commands and events specified for them in tables 18 and 19 of TS 102 622 [1], 



NOTE 1 : RQ1 is not tested in this clause, as it is effectively tested in other clauses of the present document. 
NOTE 2: ANY_GET_PARAMETER and ANY_SET_PARAIVIETER are not tested in this clause, as they are tested 

in the specific clauses for each gate for testing registry parameters. 
NOTE 3: ADM_GREATE_PIPE, ADIVI_DELETE_PIPE and ADM_CLEAR_ALL_PIPE are not tested for the host 

controller administration gate, as they are tested in the specific clauses for each command. 
NOTE 4: EVT_POST_DATA is not tested for the loop back gate, as it is tested in the clause 5.5.5. 
NOTE 5: EVT_HCI_END_OF_OPERATION is not tested for the host controller link management gate, as the 
reaction of the host controller is not specified in TS 102 622 [1]. 



5.4.2 Management gates 



5.4.2.1 



Administration gates 



5.4.2.1.1 



Host controller administration gate 



5.4.2.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.1.1 and 4.5. 



RQ4.26 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not defined in 
TS 102 622 [1] shall not be present in the registry. 



RQ6.32 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command from a requesting host, it shall 

send ADM_NOTIFY_ALL_PIPE_CLEARED to every host with at least one pipe to the requesting host. 

The registry of the host controller administration gate shall be persistent. 



RQ7.2 



RQ7.3 



The host controller shall use a default value for SESSION IDENTITY of 'FFFFFFFFFFFFFFFF'. 



RQ7.4 



The host controller shall apply the access condition of RW to SESSIONJDENTITY. 



RQ7.5 



The host controller shall only accept values of SESSIONJDENTITY of length 8 bytes. 



RQ7.6 



The host controller shall use a default value for IVIAX PIPE of between '1 0' and 7D' inclusive. 



RQ7.7 



The host controller shall apply the access condition of RO to IVIAX_PIPE. 



RQ7.8 



The host controller shall allow MAX_PIPE created dynamic pipes for the host. 



RQ7.9 



The host controller shall use a default value for WHITELIST of an empty array. 



RQ7.10 



The host controller shall apply the access condition of RW to WHITELIST. 



RQ7.11 



The host controller shall use a default value for HOST_LIST containing the list of the hosts that are accessible 
from this host controller including the host controller itself, as a list of host identifiers. 



RQ7.12 



The host controller shall apply the access condition of RO to HOST_LIST. 



RQ7.13 



The HOST_LIST shall contain the list of the hosts that are accessible from this host controller including the host 
controller itself. 



RQ7.14 



The host controller shall reject create pipe requests if the source host is not listed in the WHITELIST of the 
destination host. 



NOTE 1 : Development of test cases for R04.26 and R07.8 is FFS. 

NOTE 2: RQ7.13 is only tested in the context of RQ7.1 1 (i.e. default value). 

NOTE 3: RQ7.14 is also covered in clause 8.1.1 of TS 102 622 [1], covered by clause 5.5.1.1 of the present document. 

This RO is therefore not tested within this clause, as it is effectively tested in clause 5.5.1 .1 . 
NOTE 4: R07.2 is tested in clause 5.1 .4.3 of the present document. 



5.4.2.1.1.2 



Test case 1 : SESSION IDENTITY 



5.4.2.1.1.2.1 Test execution 

There are no test case-specific parameters for this test case. 
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5.4.2.1.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is currently open. 



5.4.2.1.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ADI\/I_CLEAR_ALL_PIPE on PIPEl with appropriate parameter as 
required by the lower layer. 




2 


HCUT^HS 


Send ANY OK. 




3 


HS ^ HCUT 


Send ANY OPEN PIPE on PIPEl. 




4 


HCUT^HS 


Send ANY OK (parameters are not checked). 




5 


HS -^ HCUT 


Send ANY GET PARAMETER(SESSION IDENTITY) on PIPEl. 




6 


HCUT ^ HS 


Send ANY_OK with parameter value 'FFFFFFFFFFFFFFFF'. 


R07.3, 
R07.4 


7 


HS ^ HCUT 


Send ANY SET PARAMETER(SESSION IDENTITY, '01 02 03 04 05 06 07 
08') on PIPEl. 




8 


HCUT^HS 


Send ANY OK. 


R07.4 


9 


HS ^ HCUT 


Send ANY GET PARAMETER{SESSION IDENTITY) on PIPEL 




10 


HCUT->HS 


Send ANY OK with parameter value '01 02 03 04 05 06 07 08'. 


RQ7.4 


11 


HS ^ HCUT 


Send ANY SET PARAMETER(SESSION IDENTITY, '01 02 03 04 05 06 
07') on PIPEL 




12 


HCUT ^ HS 


Send response containing an allowed error response code for the command. 


R07.5 



5.4.2.1.1.3 



Test case 2: MAX PIPE 



5.4.2.1.1.3.1 Test execution 

There are no test case-specific parameters for this test case. 

5.4.2.1.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is currently open. 

5.4.2.1.1.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ADM_CLEAR_ALL_PIPE on PIPE1 with appropriate parameter as 
required by the lower layer. 




2 


HCUT^HS 


Send ANY OK. 


R06.32 


3 


HS ^ HCUT 


Send ANY OPEN PIPE on PIPEL 




4 


HCUT-»HS 


Send ANY OK. 




5 


HS ^ HCUT 


Send ANY GET PARAMETER(MAX PIPE) on PIPEL 




6 


HCUT ^ HS 


Send ANY_OK with parameter value V_ MAX_PIPE. 


R07.6, 
R07.7 


7 


HS -> HCUT 


IfV MAX PIPE = '10', send ANY SET PARAMETER(MAX PIPE, '11') on 

PIPEL 

Otherwise send ANY SET PARAMETER(MAX PIPE, '10') on PIPEL 




8 


HCUT^HS 


Send response containing an allowed error response code for the command. 


R07.7 



5.4.2.1.1.4 



Testcase3:WHITELIST 



5.4.2.1.1.4.1 Test execution 

There are no test case-specific parameters for this test case. 
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5.4.2.1.1.4.2 Initial conditions 

The last value of WHITELIST in the host controller's registry is not an empty array. 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is currently open. 



5.4.2.1.1.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ADM_CLEAR_ALL_PIPE on PIPE1 with appropriate parameter as 
required by tlie lower layer. 




2 


HCUT^ HS 


Send ANY OK. 




3 


HS ^ HCUT 


Send ANY OPEN PIPE on PIPEL 




4 


HCUT^ HS 


Send ANY OK. 




5 


HS ^ HCUT 


Send ANY GET PARAMETER(WHITELIST) on PIPEL 




6 


HCUT^ HS 


Send ANY_OK with a parameter of length zero. 


RQ7.9, 
RQ7.10 


7 


HS ^ HCUT 


Send ANY SET PARAMETER(WHITELIST, '01') on PIPEL 




8 


HCUT^ HS 


Send ANY OK. 


RQ7.10 


9 


HS ^ HCUT 


Send ANY GET PARAMETER(WHITELIST) on PIPEL 




10 


HCUT^ HS 


Send ANY OK with parameter value '01 '. 


RQ7.10 



5.4.2.1.1.5 



Test case 4: HOST LIST 



5.4.2.1.1.5.1 Test execution 

There are no test case-specific parameters for this test case. 

5.4.2.1.1.5.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is currently open. 

5.4.2.1.1.5.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ADM_CLEAR_ALL_PIPE on PIPEl with appropriate parameter as 
required by the lower layer. 




2 


HCUT-^HS 


Send ANY OK. 




3 


HS ^ HCUT 


Send ANY OPEN PIPE on PIPEL 




4 


HCUT ^ HS 


Send ANY OK. 




5 


HS ^ HCUT 


Send ANY GET PARAMETER(HOST LIST) on PIPEL 




6 


HCUT-^HS 


Send ANY_OK with parameter value V_HOST_LIST. 


R07.1L 
R07.12, 
RQ7.13 


7 


HS ^ HCUT 


Send ANY SET PARAMETER(HOST LIST, 'GO') on PIPEL 




8 


HCUT ^ HS 


Send response containing an allowed error response code for the command. 


R07.12, 



5.4.2.1.2 



Host administration gate 



5.4.2.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.1.2. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.4.2.2 



Link management gate 



5.4.2.2.1 



Host controller link management gate 



5.4.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.2.1 and 4.5. 



Registry parameters whicli are in tlie range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



RQ4.26 



RQ7.15 



The host controller shall use a default value for REG ERROR of '0000'. 



RQ7.16 



The host controller shall apply the access condition of RW to REC_ERROR. 



RQ7.17 [The host controller shall only accept values of REC_ERROR of length 2 bytes. 



NOTE 1 : Development of test cases for RQ4.26 is FFS. 

NOTE 2: Test cases for RQ7. 15, RQ7.16and RQ7.1 7 are presented in TS 102 695-3 [10]. 



5.4.2.2.2 



Host link management gate 



5.4.2.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.2.2. 



R07.18 |The host controller shall only set values of REC_ERROR with length 2 bytes. 



NOTE: Test cases for RQ7.18 are presented in TS 102 695-3 [10]. 



5.4.2.3 Identity management gate 

5.4.2.3.1 Local registry 



5.4.2.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.3 and 4.5. 

NOTE: This clause covers the conformance requirements contained within TS 102 622 [1], clause 7.1.3 for the 
local registry. The requirements for the remote registry are contained in clause 5.4.2.3.2. 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in 
TS 102 622 [1] shall not be present in the registry. 



R04.26 



R07.19 



The registry of the identity management gate shall be persistent. 



RO7.20 



This gate shall be provided by all hosts and the host controller. 



R07.21 



If present in the host controller, the host controller shall use a value for VERSION_SW of length 
3 bytes. 



R07.22 



If present in the host controller, the host controller shall apply the access condition of RO to 
VERSION SW. 



R07.23 



If present in the host controller, the host controller shall use a value for VERSION_HARD of length 
3 bytes. 



R07.24 



If present in the host controller, the host controller shall apply the access condition of RO to 
VERSION HARD. 



R07.25 



If present in the host controller, the host controller shall use a value for VERSION_NAME of 
maximum length 20 bytes with UTF8 coding. 



R07.26 



If present in the host controller, the host controller shall apply the access condition of RO to 
VERSION NAME. 



R07.27 



If present in the host controller, the host controller shall use a value for MODEL_ID of length 1 byte. 



R07.28 



If present in the host controller, the host controller shall apply the access condition of RO to 
MODEL ID. 



RQ7.29 



If present in the host controller, the host controller shall apply the access condition of RO to 
HCI VERSION. 



RO7.30 



The host controller shall use a value for GATES_LIST containing the list of all gates that accept 
dynamic pipes as an array of gate identifiers. 



R07.31 



The host controller shall apply the access condition of RO to GATES_LIST. 
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RQ7.32 



A host controller according to the present document shall set the HCI_VERSION parameter if 
provided to '01'. 



NOTE 1 : Development of test cases for RQ4.26 is FFS. 

NOTE 2: RQ7.19 is not tested within this clause, as the registry contains no writeable parameters which can 

be used to test the persistence of the registry. 
NOTE 3: RQ7.20 is also covered in clause 4.3 of TS 1 02 622 [1], covered by clause 5.1 .3 of the present 

document. This RQ is therefore not tested within this clause, as it is effectively tested in clause 5.1 .3. 
NOTE 4: Test cases for RQ7.21 , RQ7.22, RQ7.23, RQ7.24, RQ7.25, RQ7.26, RQ7.27 and RQ7.28 are 
presented in TS 102 695-3 [10]. 



5.4.2.3.1 .2 Test case 1 : registry parameters 

5.4.2.3.1.2.1 Test execution 

The test procedure shall be executed for each of the parameters in the following table. 



Registry parameter 

(designated REG PARAM) 


Presence 


Expected value 

(designated VALUE) 


RQ to be checked in 
steps 2 and 6 


RQ to be checked 
in step 4 


HCI VERSION 





V HO! VERSION 


R07.32 


RQ7.29 


GATES LIST 


M 


V GATES LIST 


RO7.30 


RQ7.31 



5.4.2.3.1 .2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 



5.4.2.3.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HOUT 


Send ANY GET PARAMETER(REG PARAM) on PIPE ID MAN. 




2 


HCUT^ HS 


If REG_PARAM is supported by the device under test as indicated in 

table 4.3, send ANY_OK with parameter value equal to VALUE. 

If REG_PARAM is not supported by the device under test as indicated in 

table 4.3, send response containing an allowed error response code for the 

command. 


See test 

execution 

clause 



5.4.2.3.2 



Remote registry 



5.4.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.3. 

NOTE: This clause covers the conformance requirements contained within TS 102 622 [1], clause 7.1.3 for the 
remote registry. The requirements for the local registry are contained in clause 5.4.2.3.1. 



R07.33 



The host controller shall adhere to the access condition of RO for VERSION SW in the host. 



R07.34 



The host controller shall adhere to the access condition of RO for VERSION HARD in the host. 



R07.35 



The host controller shall adhere to the access condition of RO for VERSION NAME in the host. 



R07.36 



The host controller shall adhere to the access condition of RO for MODEL ID in the host. 



R07.37 



The host controller shall adhere to the access condition of RO for HCI VERSION in the host. 



R07.38 



The host controller shall adhere to the access condition of RO for GATES LIST in the host. 



R07.39 



The host controller shall manage backward compatibility with previous HCI versions and use only 
commands and parameters defined in the specification having the lower HCI version number between of 
the 2 hosts involved in a transaction. 
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A host controller connected to a host with higher HCI version number shall operate according to its own 
version. 



RQ7.40 



NOTE 1 : RQ7.33, RQ7.34, RQ7.35, RQ7.36, RQ7.37 and RQ7.38 are not tested, as they are non-occurrence 

RQs. 
NOTE 2: In the current version of the present document, there are no previous HCI versions. RQ7.39 is therefore 

not tested in the current version of the present document. 
NOTE 3: Development of test cases for RQ7.40 is FFS. 



5.4.2.4 



Loop back gate 



5.4.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.4 and 4.5. 



RQ4.26 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 102 622 [1] 
shall not be present in the registry. 



NOTE: Development of test cases for RQ4.26 is FFS. 



5.4.3 Generic gates 

Reference: TS 102 622 [1], clause 7.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.5 HCI procedures 
5.5.1 Pipe management 



5.5.1.1 



Pipe creation 



5.5.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.1, 5.1,6.1.3.1 and 6.1.3.2. 
These conformance requirements must be interpreted in the context of the SDL diagram in clause A.2. 



RQ6.22 


When the host controller receives an ADM_CREATE_PIPE command. It shall use the WHITELIST 
defined by the destination host in order to verify that the source host is authorized to create a pipe. 


RQ8.1 


The host controller shall verify that the destination host's administration gate WHITELIST contains 
the host identifier of the source host. If the host identifier of the source host is not part of the 
WHITELIST of the destination host , the host controller shall send 

ANY_E_PIPE_ACCESS_DENIED response to the source host and stop any further processing of 
this command. 


RQ8.2 


If the source host's host identifier is part of the WHITELIST of the destination host, the host 
controller shall continue with the procedure. 


RQ8.3 


The host controller assigns an unused pipe identifier. 


RQ8.4 


The host controller notifies the destination host that the source host requested the creation of 
PIPE,. 


R06.24 


When the host controller sends an ADM_NOTIFY_PIPE_CREATED command, the command 
parameters shall be 5 bytes long. 


RQ6.25 


When the host controller sends an ADM_NOTIFY_PIPE_CREATED command as a result of an 
ADIV1_CREATE_PIPE command being received from a host, the source Hid in the command 
parameters shall be the Hid of that host. 


RQ6.23 


When the pipe was successfully created, the host controller shall send the response ANY_OK in 
response to the ADIVI CREATE PIPE command, with parameters as specified in TS 102 622 [1]. 


RQ8.5 


The host controller responds to ADM_CREATE_PIPE that PIPE, has been created. 


RQ8.6 


When the host controller wants to create a pipe then the pipe identifier is assigned and only steps 2 
and 3 in figure 6 of TS 102 622 [1] are needed. 
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RQ8.7 



When a pipe is created towards the host controller then only steps 1 and 4 in figure 6 of 
TS 102 622 [1] are needed. 



RQ8.8 



If the host controller does not accept the creation of the pipe, it shall respond to 
ADIVICREATEPIPE with an appropriate response code. 



NOTE 1 : RQ6.22 is contained with RQ8.1 and RQ8.3; it is therefore not explicitly tested within this clause. 
NOTE 2: RQ8.4 and R06.25 are not currently tested, as they require access to the interfaces between two 

hosts and the host controller. 
NOTE 3: RQ8.5 is a duplicate of RQ6.23; it is therefore not explicitly tested within this clause. 
NOTE 5: Test cases for RQ8.1 , RQ8.2, RQ8.3, RQ8.6, RQ8.7, RQ8.8, RQ6.24 and RQ6.23 is presented in 
TS 102 695-3 [10]. 



5.5.1.2 



Pipe deletion 



5.5.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.2,6.1.3.3 and 6.1.3.4. 



RQ8.9 



After receiving a valid ADIVI_DELETE PIPE command from a host, the host controller notifies the 
destination host (with an ADIVI_NOTIFY_PIPE_DELETED command). 



RQ6.28 



When the host controller sends an ADI\/l_NOTIFY_PIPE_DELETED command, the command 
parameters shall be 1 byte long. 



RQ6.26 



The host that requested the deletion of the pipe can only be the source host or destination host. 



RQ6.27 



When the pipe is successfully deleted, the host controller shall send the response ANY_OK without 
parameters. 



RQ8.10 



When PIPEx connects to a gate at the host controller and the connecting host requests the deletion, 
then only steps 1 and 4 in figure 8 of TS 102 622 [1] are needed. 



RQ8.11 



When PIPEx connects to a gate at the host controller and the host controller requests the deletion, then 
only steps 2 and 3 in figure 8 of TS 102 622 [1] are needed. 



NOTE 1 : Further test cases for R06.26 are presented in TS 1 02 695-3 [1 0]. 

NOTE 2: Development of test cases for RQ8.9, RQ8.1 0, RQ8.1 1 and R06.28 is FFS. 



5.5.1.2.2 



Test case 1 : valid pipe deletion from host to host controller 



5.5.1.2.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.5.1.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 

• A dynamic pipe (PIPE_X) has been created from a gate on the host simulator to a gate on the host controller, 
and is currently open. 



5.5.1.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ADM DELETE PIPE(PIPE X) on PIPEl. 




2 


HCUT^ HS 


Send ANY OK with no parameters. 


R06.27, RQ6.26 
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5.5.1.3 



Clear all Pipes 



5.5.1.3.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.3,6.1.3.5 and 6.1.3.6. 



RQ6.29 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command and the data link layer 
specified in TS 102 613 [2] is used, it shall interpret the two bytes in the command parameters as the 
identity reference data, and shall use the identity reference data to initialize the reference data used by 
the host controller to check the UICC host identity. 



RQ6.30 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command, it shall delete all the 
dynamic pipes connected to the requesting host, close all static pipes connected to the requesting host 
and set all registry values related to static pipes connected to the requesting host to their default values. 



RQ6.31 



When ADIVICLEARALLPIPE is successful the host controller shall respond with an ANY_OK without 
parameters. 



RQ6.32 



When the host controller receives a valid ADM_CLEAR_ALL_PIPE command from a requesting host, it 
shall send ADM_NOTIFY_ALL_PIPE_CLEARED to every host with at least one pipe to the requesting 
host. 



RQ6.33 



When the host controller sends an ADIVI_NOTIFY_ALL_PIPE_CLEARED command with the host 
controller as the requesting host, it shall delete all dynamic pipes between the host controller and the 
host and shall close all static pipes between the host and the host controller. 



RQ6.34 



When the host controller sends an ADM_NOTIFY_ALL_PIPE_CLEARED command, the command 
parameters shall be one byte long and shall contain the Hip of the requesting host. 



5.5.1.3.2 Test case 1: identity reference data when TS 102 613 is used 

5.5.1.3.2.1 Test execution 

5.5.1.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• SYNC ID needs to match. 



5.5.1.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ADM CLEAR ALL PIPE with value 
IDENTITY REFERENCE DATA. 




2 


HCUT ^ HS 


Send ANY OK. 


RQ6.29 


3 


HS ^ HCUT 


Send ANY OPEN PIPEonPIPEI. 




4 


HCUT-^HS 


Send ANY OK. 




5 


HS ^ HCUT 


Send ANY SET PARAMETER(SESSION IDENTITY, '01 02 03 04 05 06 
07 08')onPIPE1. 




6 


HCUT ^ HS 


Send ANY OK. 




7 


User-^ 
HCUT 


Trigger the host controller to deactivate the SWP interface and then 
reactivate the SWP interface. 




8 


HCUT ^ HS 


Deactivate the SWP interface. 




9 


HCUT^HS 


Activate the SWP interface. 




10 


HS^ ^ 

HCUT 


Perform SWP interface activation using IDENTITY_REFERENCE_DATA 
as SYNC ID, and SHDLC link establishment. 




11 


HS ^ HCUT 


Send ANY OPEN PIPEonPIPEI. 




12 


HCUT ^ HS 


Send ANY OK. 


RQ6.29 



5.5.1 .3.3 Test case 2: reception of ADMCLEARALLPIPE - static pipes, dynamic pipes 

to host 

5.5.1.3.3.1 Test execution 

There are no test case-specific parameters for this test case. 
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5.5.1.3.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is open. 

• A pipe (PIPE_LOOP_BACK) has been created to the host controller's loop back gate. 



5.5.1.3.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS-» HCUT 


Send ADM CLEAR ALL PIPE. 




2 


HCUT^ HS 


Send ANY OK. 


R06.31 


3 


HCUT^ HS 


Wait for a reasonable delay for the host controller to send a command on 

PIPEL 

If host controller sends a command on PIPEl , perform step 4. 

If host controller doesn't send a command on PIPEl , perform steps 5 to 8. 




4 




Check that the command sent in step 3 is ANY OPEN PIPE (see note). 


RO6.30 


5 


HS^ HCUT 


Send ADM_CREATE_PIPE on PIPEl , with source and destination Gid = Gid 
of identity management gate. 




6 


HCUT^ HS 


Send response containing an allowed error response code for the command. 




7 


HS^ HCUT 


Send ANY OPEN PIPE on PIPEL 




8 


HCUT^ HS 


Send ANY OK. 


RO6.30 


9 


HS^ HCUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




10 


HCUT^ HS 


Send no response or send response containing an allowed error response 
code for the command. 


RO6.30 


NOTE: The host simulator must respond appropriately to this command, independently of what command has 
been sent. 



5.5.2 Registry access 

Reference: TS 102 622 [1], clause 8.2. 
There are no new conformance requirements for the terminal for the referenced clause. 

5.5.3 Host ancJ Gate discovery 

Reference: TS 102 622 [1], clause 8.3. 
There are no conformance requirements for the terminal for the referenced clause. 

5.5.4 Session initialization 



5.5.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 8.4. 



RQ8.12 



In case the lower layer identity check fails, the host controller shall execute only the following commands: 
ANY_OPEN_PIPE, ADM_CLEAR_ALL_PIPE, ANY_GET_PARAMETER, and only if these are sent on 
PIPE.. 



RQ8.13 



In case the lower layer identity check fails, the host controller shall return ANY_E_INHIBITED to all 
commands, except for ANY_OPEN_PIPE, ADM_CLEAR_ALL_PIPE, ANY_GET_PARAIVIETER on 
PIPEL 



RQ8.14 



In case the lower layer identity check fails, the host controller shall ignore all events on all pipes. 
In case the lower layer identity check fails, the host controller shall return the default value of the 
SESSIONJDENTITY. However the value of the SESSIONJDENTITY in the registry remains 
unchanged. 



RQ8.15 



RQ8.16 



The inhibited state shall be terminated after processing a valid ADI\/I_CLEAR_ALL_PIPE command. 
In case the lower layer identity check passes, the host controller shall not enter the inhibited state. 



RQ8.17 
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5.5.4.2 



Test case 1 : inhibited state 



5.5.4.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.5.4.2.2 Initial conditions 

The last value of SESSION_IDENTITY in the host controller's registry is not 'FFFFFFFFFFFFFFFF'. 
A pipe (PIPE_ID_MAN) has previously been created to the host controller's identity management gate. 
A pipe (PIPE_LOOP_BACK) has previously been created to the host controller's loop back gate. 
The host simulator is currently powered down. 
PIPEl needs to be open 



5.5.4.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS 


Change the host configuration such that the lower layer identity check 
mechanism will fail. 




2 


User ^ HCUT 


Trigger the host controller to power up and to activate the lower layer. 




3 


HCUT^ HS 


Power up and activate the lower layer. 




4 


HS^ HCUT 


Send ANY OPEN PIPE on PIPEO. 




5 


HCUT^ HS 


Send ANY E INHIBITED. 


R08.13 


6 


HS^ HCUT 


Send ANY GET PARAMETER(REC ERROR) on PIPEO. 




7 


HCUT^ HS 


Send ANY E INHIBITED. 


R08.13 


8 


HS^ HCUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




9 


HCUT^ HS 


Send ANY E INHIBITED. 


R08.13 


10 


HS^ HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




11 


HCUT^ HS 


Send ANY E INHIBITED. 


R08.13 


12 


HS^ HCUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




13 


HCUT^ HS 


Send ANY E INHIBITED. 


R08.13 


14 


HS^ HCUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




15 


HCUT^ HS 


No messages on PIPE LOOP BACK. 


R08.14 


16 


HS^ HCUT 


Send ANY OPEN PIPE on PIPEl. 




17 


HCUT ^ HS 


Send response (contents are not checked). 


R08.12 


18 


HS^ HCUT 


Send ANY GET PARAMETER(SESSION IDENTITY) on PIPEl. 




19 


HCUT^ HS 


Send ANY OK with parameter value 'FF FF FF FF FF FF FF FF'. 


R08.15 


20 


HS^ HCUT 


Send ADM_CREATE_PIPE with source Gid = 'EE' and destination Gid = Gid 
of identity management gate. 




21 


HCUT^ HS 


Send ANY E INHIBITED. 


R08.13 


22 


HS^ HCUT 


Send ANY CLOSE PIPE on PIPEl. 




23 


HCUT^ HS 


Send ANY E INHIBITED. 


R08.13 


24 


HS^ HCUT 


Send ADM DELETE PIPE(PIPE ID MAN) on PIPEl. 




25 


HCUT^ HS 


Send ANY E INHIBITED. 


R08.13 


26 


HS^ HCUT 


Send ADM CLEAR ALL PIPE on PIPEl. 




27 


HCUT^ HS 


Send ANY OK. 




28 


HS^ HCUT 


Send ANY OPEN PIPE on PIPEl. 




29 


HCUT^ HS 


Send ANY OK. 




30 


HS^ HCUT 


Send ANY OPEN PIPE on PIPEO. 




31 


HCUT^ HS 


Send ANY OK. 


RQ8.16 


32 


HS^ HCUT 


Send ADM SET PARAMETER(SESSION IDENTITY, '01 02 03 04 05 06 07 
08') on PIPEl. 




33 


HCUT^ HS 


Send ANY OK. 


R08.16 


NOTE: After step 3 if the host controller sends comments the host simulator shall respond according to its 
initial state. 



£75/ 



Release 8 



40 



ETSI TS 102 695-1 V8.0.0 (2011-06) 



5.5.4.3 



Test case 2: inhibited state, followed by subsequent successful identity check 



5.5.4.3.1 Test execution 

There are no test case-specific parameters for this test case. 

5.5.4.3.2 Initial conditions 

• The last value of SESSION_IDENTITY in the host controller's registry is not 'FFFFFFFFFFFFFFFF'. 

• The host simulator is currently powered down. 



5.5.4.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS 


Change the host configuration such that the lower layer identity check 
mechanism will fail. 




2 


User ^ HCUT 


Trigger the host controller to power up and to activate the lower layer. 




3 


HCUT^ HS 


Power up and activate the lower layer. 




4 


HS^ HCUT 


Send ANY OPEN PIPE on PIPEO. 




5 


HCUT-» HS 


Send ANY E INHIBITED. 




6 


User ^ HCUT 


Trigger the host simulator to be powered down. 




7 


HCUT^ HS 


Power down the host simulator. 




8 


HS 


Change the host configuration such that the lower layer identity check 
mechanism will pass. 




9 


User ^ HCUT 


Trigger the host simulator to be powered up. 




10 


HCUT^ HS 


Power up the host simulator. 




11 


HS^ HCUT 


Send ANY OPEN PIPEonPIPEI. 




12 


HCUT^ HS 


Send response (contents are not checked). 




13 


HS^ HCUT 


Send ANY GET PARAMETER(SESSION IDENTITY) on PIPE1. 




14 


HCUT^ HS 


Send ANYOK with parameter value containing the same value as previously 
set (see initial conditions). 


R08.15 


15 


HS^ HCUT 


Send ADM SET PARAMETER(SESSION IDENTITY, '01 02 03 04 05 06 07 
08') on PIPE1. 




16 


HCUT-> HS 


Send ANY OK. 


R08.17 


NOTE: After step 3 if the host controller sends comments the host simulator shall respond according to its 
initial state. 



5.5.5 Loop back testing 

5.5.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 8.5. 



R08.18 



The host controller shall accept the creation of a pipe to its loop back gate from any gate in another host. 



R08.19 



When the host controller receives the event EVT_POST_DATA on a pipe connected to its loop back 
gate, it shall send back the event EVT_POST_DATA with same data as received in the received 
EVT POST DATA. 



RQ8.20 



The loopback gate shall support at least all messages with size up to 250 bytes. 



5.5.5.2 



Test case 1 : processing of EVT_POST_DATA 



5.5.5.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 
• EVT_POST_DATA data sizes of 250 bytes. 
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5.5.5.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_LOOP_BACK) has been created to the host controller's loop back gate using source Gid : '1 1 ' 
and is open. 



5.5.5.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send EVT_POST_DATA on PIPE_LOOP_BACK containing data of the 
specified size. 




2 


HCUT^ HS 


Send EVT_POST_DATA on PIPE_LOOP_BACK containing the same data 
as in step 1 . 


RQ8.19, 
RQ8.20 



5.6 



Contactless card emulation 



5.6.1 Overview 

5.6.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.1. 



RQ9.1 



The CLF shall handle the RF communication layers to the external contactless reader. 



RQ9.2 



The host controller has one card RF gate for each RF technology it supports. 



RQ9.3 



For the contactless platform for card emulation mode the pipes to card RF gates shall be created, 
opened, closed and deleted by the host. 



RQ9.4 



The RF technology of a card RF gate is active when there is an open pipe connected to it. 



RQ9.5 



The host controller shall activate one or more RF technologies as requested by the host to the external 
reader. 



NOTE: Development of test cases for RQ9.3 is FFS. 



5.6.1.2 Test case 1 : RF gate of type A 

5.6.1.2.1 Test execution 

There is no test case specific parameters for this test case. 

5.6.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is currently open. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type A protocol is powered on. 
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5.6.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with source Gid = '23' and 
destination Gid = Gid of type A card RF gate; designate the created pipe 
PIPEa. 




2 


HCUT^HS 


Send ANY_OK. 


RQ9.2, 


3 


HS -» HCUT 


Send ANY OPEN PIPE on PIPEa. 




4 


HCUT-»HS 


Send ANY OK. 




5 


HS ^ HCUT 


Send ANY GET PARAMETER (MODE) on PIPEa. 




6 


HCUT ^ HS 


Send ANY OK with a parameter value of 'FF'. 




7 


HS ^ HCUT 


Send ANY SET PARAMETER (MODE, '02') on PIPEa. 




8 


HCUT^HS 


Send ANY OK. 




9 


PCD ^ HCUT 
HCUT ^ PCD 


Perform anti-collision as described in ISO/IEC 14443-3 [6] Type A. 


RQ9.1, 
RQ9.4, 
RQ9.5 



5.6.1.3 Test case 2: RF gate of type B 

5.6.1.3.1 Test execution 

There is no test case specific parameters for this test case. 

5.6.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEl is currently open. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type B protocol is powered on. 

5.6.1 .3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ADM_CREATE_PIPE on PIPE1, with source Gid = '21' and 
destination Gid = Gid of type B card RF gate; designate the created pipe 
PIPEa. 




2 


HCUT^HS 


Send ANY_OK. 


RQ9.2, 


3 


HS ^ HCUT 


Send ANY OPEN PIPE on PIPEa. 




4 


HCUT^HS 


Send ANY OK. 




5 


HS ^ HCUT 


Send ANY GET PARAMETER (MODE) on PIPEa. 




6 


HCUT^HS 


Send ANY OK with a parameter value of 'FF'. 




7 


HS ^ HCUT 


Send ANY SET PARAMETER (MODE, '02') on PIPEa. 




8 


HCUT ^ HS 


Send ANY OK. 




9 


PCD ^ HCUT 
HCUT ^ PCD 


Perform anti-collision as described in ISO/IEC 14443-3 [6] Type B. 


RQ9.1, 
RQ9.4, 
RQ9.5 



5.6.2 Void 

Reference: TS 102 622 [1], clause 9.2. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.6.3 Gates 

5.6.3.1 Void 

Reference: TS 102 622 [1], clause 9.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.2 Identity management gate 
5.6.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.2. 



RQ9.6 



If low power mode is supported, the parameter LOW_POWER_SUPPORT of identity management gate 
shall be '01'. 



RQ9.7 



If low power mode is not supported, the parameter LOWPOWERSUPPORT of identity management 
gate shall be '00'. 



RQ9.8 



The host controller shall apply the access condition of RO to LOW_POWER_SUPPORT. 



5.6.3.3 Card RF gates 

5.6.3.3.1 Overview 

Reference: TS 102 622 [1], clause 9.3.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.3.2 Commands 

5.6.3.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.3.3 Events and subclauses 

5.6.3.3.3.1 Events 

5.6.3.3.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.3. 



RQ9.10 [The Card RF gates shall support the EVT_SEND_DATA event. 



NOTE: RQ1 is tested in clause 5.6.4. 



5.6.3.3.3.2 EVT_SEND_DATA 

Reference: TS 102 622 [1], clause 9.3.3.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.6.3.3.4 Registry and subclauses 

5.6.3.3.4.1 Registry 



5.6.3.3.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4. 



RQ9.1 1 |AII registries shall be persistent. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.3.3.4.2 



RF technology type A 



5.6.3.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.1. 



RQ9.12 



The CLF shall only accept values of MODE of 'FF' and '02'. 



R09.13 



The CLF shall set a default value for MODE of 'FF'. 



R09.14 



The CLF shall apply the access condition of RW for MODE. 



R09.15 



The CLF shall use a default value for UID_REG of length zero bytes. 



R09.16 



If Length of UID_REG equals then the CLF generates a single size DID with uidO : 
as random numbers. 



='08'and uid1 to uid3 



R09.17 



The random numbers shall be generate only on state transitions POWER_OFF to IDLE state (state 
definitions according to ISO/IEC 14443-3 [6]) The CLF shall interpret the absence of an RF-field as 
POWER-OFF state. 



R09.18 



If Length equals 4, 7 or 10 then the CLF shall use UID_REG as UID. 



R09.19 



The CLF shall apply the access condition of WO for UIDREG. 



RQ9.20 



The CLF shall set a default value for SAK of '00'. 



RQ9.21 



The CLF shall apply the access condition of RW for SAK. 



R09.22 



The CLF shall set a default value for ATQA of '0000'. 



R09.23 



The CLF shall apply the access condition of RW for ATQA. 



R09.24 



The CLF shall set a default value for APPLICATION DATA of 'N1 =0'. 



RQ9.25 



The CLF shall apply the access condition of RW for APPLICATION_DATA. 



R09.26 



The CLF shall set a default value for FWI, SFGI of 'EE'. 



R09.27 



The CLF shall apply the access condition of RW for FWI, SFGI. 



R09.28 



If CID_SUPPORT ='01' the CLF shall set CID support in the ATS. 



R09.29 



Void 



RO9.30 



The CLF shall set a default value for CID SUPPORT of '00'. 



R09.31 



The CLF shall apply the access condition of RW for CID_SUPPORT. 



R09.32 



If the CLF contains a tunneling mode capability for type A ISO/IEC 14443-4 [7] non compliant protocol 
support then the value of CLT_SUPPORT shall be '01'. 



RQ9.33 



If the CLF does not contain a tunneling mode capability for type A ISO/IEC 14443-4 [7] non compliant 
protocol support then the value of CLT_SUPPORT shall be '00'. 



R09.34 



The CLF shall apply the access condition of RO to CLT_SUPPORT. 



R09.35 



The host controller shall support DATARATE_MAX which codes maximum divisor supported with coding 
as defined in TS 102 622 [1] where: 

• Byte 1 defines the maximum divisor supported in direction PCD to PICC. 

• Byte 3 defines the limitation to support different divisors for each direction. 



R09.36 



The CLF shall set a default value for DATARATE MAX of '030300'. 



R09.37 



The CLF shall apply the access condition of RW for DATARATE_MAX. 



R09.38 



The CLF shall use the minimum of the value indicated in the registry and the maximum divisor 
implemented in the CLF as the maximum support divisor indicated in TA (1) as defined in ISO/IEC 
14443-4 [7], 



R09.39 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



NOTE 1: Test cases for R09. 12, R09.13and R09.1 4 are presented in TS 102 695-3 [10]. 
NOTE 2: Further test cases for RQ9. 18, RQ9.21, R09.23, R09.26 and RQ9.27 are presented in 

TS 102 695-3 [10]. 
NOTE 3: Development of test cases for RQ 9.39 is FFS. 
NOTE 4: Development of test cases for RQ 9.32, RQ 9.33 and RQ 9.34 is FFS. 
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Test case 1: UID REG - default 



5.6.3.3.4.2.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• This test case is assumed that only one HCUT (PICC) is presented in the RF field. 

5.6.3.3.4.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gid = ' 23' to the card RF gate of type A. 

• The Proximity Coupling Device (PCD) supports ISO/IEC 14443-3 [6] Type A. 

• MODE is set to '02'. 



5.6.3.3.4.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HCUT 


The terminal is placed in PCD field. 




2 


PCD ^ HCUT 


Transitions from POWER OFF to IDLE state. 




3 


PCD ^ HCUT 


Send REQA. 




4 


HCUT^PCD 


Send ATQA and enter the READY state. 




5 


PCD^HCUT 


Send AC command. 




6 


HCUT^ PCD 


Send the complete UID, with UIDO = '08', UID1-UID3 randomly generated 
by the CLF. 


RQ9.15, 
RQ9.16, 
RQ9.17 


7 


PCD ^ HCUT 


Return to the IDLE state by sending REOA twice. 




8 


HCUT^ PCD 


Send ATQA and enter the READY state. 




9 


PCD -> HCUT 


Send AC command. 




10 


HCUT ^ PCD 


Send UID as it given in step 6. 


RQ9.16, 
RQ9.17 


11 


PCD ^ HCUT 


Send SELECT command with received UID. 




12 


HCUT-» PCD 


Send SAK (UID is complete). 




13 


PCD ^ HCUT 


Send HLTA command to enter the HALT state. 




14 


PCD -» HCUT 


Send WUPA. 




15 


HCUT^ PCD 


Send ATQA. 




16 


PCD -^ HCUT 


Send SELECT command with received UID step 6. 




17 


HCUT^ PCD 


Send SAK (UID is complete). 


RQ9.16, 
RQ9.17 



5.6.3.3.4.2.3 



Test case 2: SAK 



5.6.3.3.4.2.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• This test case is assumed that only one HCUT (PICC) is presented in the RF field: 

Single UID of length 4. 

5.6.3.3.4.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gid = '23' to the card RF gate of type A. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type A protocol is powered off. 

• MODE is set to '02'. 
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5.6.3.3.4.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS-^ HCUT 


Send ANY GET PARAMETER (ATQA) on PIPEa. 




2 


HCUT^ HS 


Send ANY_OK with value '0000'. 


RQ9.22, 
R09.23 


3 


HS^ HCUT 


Send ANY GET PARAMETER (SAK) on PIPEa. 




4 


HCUT^ HS 


Send ANY_OK with parameter '00'. 


RQ9.20, 
R09.21 


5 


User ^ HCUT 


The terminal is placed in PCD field. 




6 


PCD ^ HCUT 


Transitions from POWER OFF to IDLE state. 




7 


PCD ^ HCUT 


Send REOA. 




8 


HCUT ^ PCD 


Send ATOA and enter READY state. 




9 


PCD ^ HCUT 


Send AC command. 




10 


HCUT -» PCD 


Send UID. 




11 


PCD ^ HCUT 


Send SELECT command with received UID. 




12 


HCUT ^ PCD 


Send SAK (UID is complete) with the default value. 


R09.21 



5.6.3.3.4.2.4 Test case 3: ATS - default parameters 

5.6.3.3.4.2.4.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• ATS with default value for all parameters. 

5.6.3.3.4.2.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gid = '23' to the card RF gate of type A. 

• ISO/IEC 14443-3 [6] Type A is in ACTIVE state. 

• SAK is set to '20'. 



5.6.3.3.4.2.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


PCD ^ HCUT 


Send RATS. 




2 


HCUT-> PCD 


Send ATS. 


R09.24, 
R09.26, 
RO9.30, 
R09.32, 
R09.33, 
R09.36 



5.6.3.3.4.2.5 



Test case 4: APPLICATION DATA 



5.6.3.3.4.2.5.1 Test execution 

Run this TC for the following parameters: 

• CIDa = 01. 

• ISO/IEC 78 16-4 [8] historical bytes (Tl - Tk) is defined as: 

Category indicator: '80'. 

Card service data: '31', 'EC. 

Card capabilities: '73', '66', '21' , '15'. 
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5.6.3.3.4.2.5.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gjd = '23' to the card RF gate of type A. 

• MODE is set to 'FF' and SAK is set to '20'. 



5.6.3.3.4.2.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS -^ HCUT 


Send ANY SET PARAMETER (CID SUPPORT, 'CID') on PIPEa 




2 


HCUT ^ HS 


Send ANY OK 


R09.31 


3 


HS ^ HCUT 


Send ANY GET PARAMETER (CID SUPPORT) on PIPEa 




4 


HCUT^HS 


Send ANY OK with value given in step 1 


R09.31 


5 


HS ^ HCUT 


Send ANY SET PARAMETER (APPLICATION DATA, Tl-Tk) on PIPEa 




6 


HCUT ^ HS 


Send ANY OK 


R09.25 


7 


HS -^ HCUT 


Send ANY GET PARAMETER (APPLICATION DATA) on PIPEa 




8 


HCUT ^ HS 


Send ANY OK with value (T1 -Tk) given in step 1 


R09.25 


9 


HS ^ HCUT 
HCUT ^ HS 


Set the MODE parameter to '02' 




10 


PCD -^ HCUT 
HCUT^ PCD 


Perform initialization of RF ISO/IEC 14443-3 [6] Type A (with anti-collision 
and selection). 




11 


PCD ^ HCUT 


Send RATS 




12 


HCUT^ PCD 


Send ATS with historical bytes (APPLICATION_DATA)as defined in step 1 


R09.25 
R09.28 



5.6.3.3.4.2.6 



Test case 5: DATARATE MAX 



5.6.3.3.4.2.6.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• DATARATE_MAX = '000001'. 

• DATARATE_MAX = '030300'. 

5.6.3.3.4.2.6.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gid = ' 23' to the card RF gate of type A. 

• MODE is set to 'FF' and SAK is set to '20'. 



5.6.3.3.4.2.6.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ANY GET PARAMETER (DATARATE MAX) on PIPEa. 




2 


HCUT-» HS 


Send ANY_OK with default value. 


RQ9.35, 
RQ9.36, 
R09.37 


3 


HS-^ HCUT 


Send ANY SET PARAMETER (DATARATE MAX, 'Bytel Byte2 Byte3') 
on PIPEa. 




4 


HCUT^ HS 


Send ANY_OK. 


RQ9.35, 
R09.37 


5 


HS ^ HCUT 
HCUT^ HS 


Set the MODE parameter to '02' 




6 


PCD ^ HCUT 
HCUT^ PCD 


Perform initialization of RF ISO/IEC 14443-3 [6] Type A (with anti-collision 
and selection). 




7 


PCD ^ HCUT 


Send RATS. 




8 


HCUT^ PCD 


Send ATS with TA(1) value compliant with DATARATE_MAX. 


R09.38 
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5.6.3.3.4.3 



RF technology type B 



5.6.3.3.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.2. 



RQ9.40 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



RQ9.41 



The CLF shall only accept values of MODE of 'FF' and '02'. 



RQ9.42 



The CLF shall set a default value for MODE of 'FF'. 



R09.43 



The CLF shall apply the access condition of RW for MODE. 



RQ9.44 



The CLF shall only accept values of PUPI of length or 4 bytes. 



RQ9.45 



If N=0 then the CLF shall generate the PUPI as dynamically generated number. 



RQ9.46 



The PUPI shall only be generated by a state transition from the POWER-OFF to the IDLE state(state 
definitions according to ISO/IEC 14443-3 [6]). 



R09.47 



The CLF shall interpret the absence of an RF-field as POWER-OFF state. 



R09.48 



If N is not equal to 0, the CLF shall use the PUPI_REG as PUPI. 



R09.49 



The CLF shall apply the access condition of WO for PUPI_REG. 



RQ9.50 



The CLF shall use the AFI registry parameter as AFI according to ISO/IEC 14443-3 [6]. 



R09.51 



The CLF shall set a default value for AFI of '00'. 



R09.52 



The CLF shall apply the access condition of RW to AFI. 



R09.53 



The CLF shall set a default value for ATOB of '00 00 00 E4'. 



R09.54 



The CLF shall only accept values of ATOB of length 4 bytes. 



R09.55 



The CLF shall set additional data for ATOB as defined in the registry Table 31 of TS 1 02 622 [1], 



R09.56 



The CLF shall apply the access condition of RW to ATOB. 



R09.57 



The CLF shall set higher layer response in answer to ATTRIB command as defined registry. 



R09.58 



The CLF shall set a default value for HIGHER LAYER RESPONSE of 'N2=0'. 



R09.59 



The CLF shall apply the access condition of RW for HIGHER_LAYER_RESPONSE. 



RO9.60 



The host controller shall support DATARATE_MAX which codes maximum bit rates supported with 
coding as defined in TS 102 622 [1] where: 

• Byte 1 defines the maximum bit rates supported in direction PCD to PICC. 

» Byte 3 defines the limitation of having the bit rate in both direction. 



R09.61 



The CLF shall set a default value for DATARATE MAX of '030300'. 



R09.62 



The CLF shall apply the access condition of RW for DATARATE_MAX. 



R09.63 



The CLF shall set a default value for ATOB of length 0. 



R09.64 



The CLF shall use the minimum of the value indicated in the registry and the maximum bit rate supported 
implemented in the CLF as the maximum bit rate indicated in the first byte of the protocol information as 
defined in ISO/IEC 14443-3 [6]. 



NOTE 1 : Development of test cases for RO9.40 and R09.64 is FFS. 

NOTE 2: Further test cases for R09.41 , RQ9.42 and RQ9.43 are presented in TS 1 02 695-3 [1 0]. 



5.6.3.3.4.3.2 



Test case 1 : PUPI REG - default 



5.6.3.3.4.3.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• default PUPI_REG parameter. 

• REQB with API = 00 and PARAM = 00, so all PICCs shall process this REQB/WUPB. 

5.6.3.3.4.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gid = '21' to the card RF gate of type B. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type B protocol is powered off. 

• MODE is set to '02'. 



£75/ 



Release 8 



49 



ETSI TS 102 695-1 V8.0.0 (2011-06) 



5.6.3.3.4.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS -^ HCUT 


Send ANY GET PARAMETER (PUPI REG) on PIPEa. 




2 


HCUT^HS 


Send response containing an allowed error response code for the 
command. 


R09.49 


3 


User^PCD 


The terminal is placed in PCD field. 




4 


PCD ^ HCUT 


Transitions from POWER OFF to IDLE state. 




5 


PCD ^ HCUT 


Send REOB. 




6 


HCUT^ PCD 


Send ATOB with PUPI dynamically generated number. 


R09.45, 
R09.46, 
R09.47 


7 


PCD ^ HCUT 


Return to the IDLE state by sending REOB. 




8 


HCUT^ PCD 


Send ATOB with PUPI value given in step 6. 


RQ9.46 


9 


PCD ^ HCUT 


Send ATTRIB request with a non-matching PUPI with the one given in 
step 8. 




10 


HCUT ^ PCD 


Send no response. 




11 


PCD ^ HCUT 


Send HLTB to enter the HALT state. 




12 


HCUT-» PCD 


Answer to HLTB. 




13 


PCD ^ HCUT 


SendWUPB. 




14 


HCUT^ PCD 


Send ATOB with PUPI value given in step 6. 


R09.46, 
R09.47 



5.6.3.3.4.3.3 Test case 2: ATQB - verify the different parameter 

5.6.3.3.4.3.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• PUPIa = '01 02 03 04', AFIa = 40' and ATQB is coded for the following values: 

Protocol information is coded PROTOJNFO = '70'. 

Numbers of Applications byte is coded for, NUMBER_APLI = 0-15. 

• PUPIa = '12 34 56 78', AFIa = '20' and ATQB is coded for the following values: 

Protocol information is coded PROTOJNFO = '85'. 

Numbers of Applications byte is coded for, NUMBER_APLI = 0-15. 

5.6.3.3.4.3.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gid = '21' to the card RF gate of type B. 

• The Proximity Coupling Device (PCD) supports ISO/IEC 14443-3 [6] Type B. 

• MODE is set to 'FF'. 
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Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS -^ HCUT 


Send ANY GET PARAMETER (PUPI REG) on PIPEa. 




2 


HCUT^HS 


Send response containing an allowed error response code for the 
command. 


RQ9.49 


3 


HS ^ HCUT 


Send ANY SET PARAMETER (PUPI REG, 'PUPIa') on PIPEa. 




4 


HCUT-^HS 


Send ANY_OK. 


RQ9.44, 
RQ9.49 


5 


HS -^ HCUT 


Send ANY GET PARAMETER (API) on PIPEa. 




6 


HCUT ^ HS 


Send ANY_OK with value '00'. 


RQ9.51, 
RQ9.52 


7 


HS ^ HCUT 


Send ANY SET PARAMETER (API, 'API') on PIPEa. 




8 


HCUT-^HS 


Send ANY_OK. 


RQ9.50, 
RQ9.52 


9 


HS ^ HCUT 


Send ANY GET PARAMETER (ATQB) on PIPEa. 




10 


HCUT^HS 


Send ANY_OK with value'OO 00 00 E4. 


RQ9.53, 
RQ9.54 
RQ9.55, 
RQ9.56, 
RQ9.63 


11 


HS ^ HCUT 


Send ANY SET PARAMETER (ATQB, 'PROTO INFO, NUMBER APLI') 
on PIPEa. 




12 


HCUT ^ HS 


Send ANY_OK. 


RQ9.54 
RQ9.55, 
RQ9.56 


13 


HS ^ HCUT 


Send ANY GET PARAMETER (ATQB) on PIPEa. 




14 


HCUT ^ HS 


Send ANY_OK with value 'PROTOJNFO, NUMBER_APLI'. 


RQ9.54 
RQ9.55, 
RQ9.56 


15 


HS -> HCUT 
HCUT^HS 


Set the MQDE parameter to '02' 




16 


User ^ HCUT 


The terminal is placed in PCD field. 




17 


PCD ^ HCUT 


Transitions from PQWER OFF to IDLE state. 




18 


PCD -^ HCUT 


Send REQB to enter the READY state. 




19 


HCUT^ PCD 


Send ATQB with parameters as defined for: 

• PUPI same value as given in step 3. 

• API same value as given in step 7. 

• ATQB other parameters with the same values as given in step 1 1 . 


RQ9.54, 
RQ9.55, 
RQ9.56, 
RQ9.47, 
RQ9.48, 
RQ9.50 



5.6.3.3.4.3.4 



Test case 3: HIGHER LAYER RESPONSE 



5.6.3.3.4.3.4.1 Test execution 

The test procedure shall be executed once for each of following parameters: 
• HIGHER_LAYER is coded for the following values. 



HIGHER_LAYER_RESPONSE 
registry value 


Higher layer - INF to be included 

in ATTRIB command sent by 

PCD 


Expected Higher layer Response to be 

included in answer to ATTRIB command 

sent by CLP 


'01 02 03 04 05 06 07 08 09 OA' 


'11 12 13 1415' 


'01 02 03 04 05 06 07 08 09 OA' 



• D AT AR ATE_M AXa = ' 00000 1 ' 

5.6.3.3.4.3.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gjd = '2T to the card RF gate of type B. 
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• The Proximity Coupling Device (PCD) supports ISO/IEC 14443-3 [6] Type B. 

• MODE parameter is set to 'FF' 

5.6.3.3.4.3.4.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS ^ HCUT 


Send ANY GET PARAMETER (DATARATE MAX) on PIPEa. 




2 


HCUT^HS 


Send ANY_OK with value '030300'. 


RQ9.60, 
RQ9.61, 
RQ9.62 


3 


HS ^ HCUT 


Send ANY SET PARAMETER (DATARATE MAX, 'DATARATE MAXa') 
on PIPEa. 




4 


HCUT ^ HS 


Send ANY_OK. 


RQ9.60, 
RQ9.62 


5 


HS ^ HCUT 


Send ANY GET PARAMETER (HIGHER LAYER RESPONSE) on 
PIPEa. 




6 


HCUT ^ HS 


Send ANYOK with parameter value of length zero. 


RQ9.58, 
RQ9.59 


7 


HS ^ HCUT 


Send ANY SET PARAMETER (HIGHER LAYER RESPONSE, 
'HIGHER LAYERa') on PIPEa. 




8 


HCUT ^ HS 


Send ANY_OK. 


RQ9.58, 
RQ9.59 


9 


HS ^ HCUT 


Send ANY GET PARAMETER (HIGHER LAYER RESPONSE) on 
PIPEa. 




10 


HCUT ^ HS 


Send ANY_OK with value ' HIGHER_LAYERa' as given in step 7. 


RQ9.58, 
RQ9.59 


11 


HS ^ HCUT 
HCUT^HS 


Set the MODE parameter to '02' 




12 


User -» HCUT 


The terminal is placed in PCD field. 




13 


PCD ^ HCUT 


Send REQB. 




14 


HCUT^ PCD 


Send ATQB. 


RQ9.60 
RQ9.61 


15 


PCD ^ HCUT 


Send ATTRIB. 




16 


HCUT-» PCD 


Send Answer to ATTRIB. 


RQ9.57, 
RQ9.60 



5.6.3.3.4.4 



RF technology type B' 



5.6.3.3.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.3. 
NOTE: Defining conformance requirements is out of scope of the present document. 
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5.6.3.3.4.5 RF technology Type F (ISO/I EC 18092 212 kbps/424 kbps card emulation only) 

5.6.3.3.4.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.4. 



RQ9.65 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



RQ9.66 



The CLF shall only accept values of MODE of 'FF' and '02'. 



RQ9.67 



The CLF shall set a default value for MODE of 'FF'. 



R09.68 



The CLF shall apply the access condition of RW for MODE. 



RQ9.69 



The CLF shall support the capabilities indicated in the SPEED_CAP parameter as specified in 
TS102 622[1]. 



RQ9.70 



The CLF shall apply the access condition of RO to SPEED_CAP. 



RQ9.71 



The CLF shall contain a tunneling mode capability for type F card emulation anti-collision support if 
CLT SUPPORT='01'. 



RQ9.72 



The CLF shall not contain a tunneling mode capability for type F card emulation anti-collision support if 
CLT SUPPORT ='00'. 



RQ9.73 



The CLF shall apply the access condition of RO to CLT_SUPPORT. 



NOTE: Development of test cases for above listed ROs is FFS. 



5.6.3.4 Card application gates 

5.6.3.4.1 Overview 

Reference: TS 102 622 [1], clause 9.3.4.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.4.2 Commands 

5.6.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.4.3 Events and subclauses 

5.6.3.4.3.1 Events 

5.6.3.4.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3. 



RQ9.74 [When sending to a card application gate, the CLF shall respect the values and events as listed. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.6.3.4.3.2 EVT_FIELD_ON 

5.6.3.4.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.1. 



RQ9.75 



When EVT_FIELD_ON is sent by the host controller, it shall be sent within 2 ms after the detection of an 
RF field. 



RQ9.76 



In case of an underlying data link layer according to TS 102 613 [2], if SWP is in DEACTIVATED state, 
the CLF shall activate the interface instead of sending the EVT_FIELD_ON. 



RQ9.77 [When the host controller sends EVT_FIELD_ON, It shall not contain parameters. 



NOTE: All conformance requirements for the referenced clause are included in the subclauses of clause 5.6.4 of 
the present document. 



5.6.3.4.3.3 EVT_CARD_DEACTIVATED 

5.6.3.4.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.2. 



RQ9.78 [When the host controller sends EVT_CARD_DEACTIVATED, it shall not contain parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.3.4.3.4 EVT_CARD_ACTIVATED 

5.6.3.4.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.3. 



R09.79 [When the host controller sends EVT_GARD_ACTIVATED, it shall not contain parameters. 



NOTE: Development of test cases for above listed ROs is FFS. 



5.6.3.4.3.5 EVT_FIELD_OFF 

5.6.3.4.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.4. 



RO9.80 [When the host controller sends EVT_FIELD_OFF, it shall not contain parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.3.4.3.6 EVT_SEND_DATA 

5.6.3.4.3.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.5. 



R09.81 I On sending EVT_SEND_DATA the CLF shall set the last parameter byte as RF error indicator. 



NOTE: Development of test cases for above listed ROs is FFS. 



5.6.3.4.4 Registry 

5.6.3.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.4. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.6.4 Procedures 



5.6.4.1 



Use of contactless card application 



5.6.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 9.4.1 and 9.3.4.3.1. 

NOTE: These requirements apply for usage of ISO/lEC 14443-4 [7]. 



RQ9.82 



In full power mode, when the CLF detects a RF field, the card RF gate shall send the event 
EVT_FIELD_ON to the card application gate unless otherwise as specified in clause 9.3.4.3.1 . 



RQ9.83 



When there are multiple open card RF gates the CLF shall send the EVT_FIELD_ON to the open card 
application gate with the lowest Gip. 



RQ9.84 



When the CLF detects a RF field, and after sending EVT_FIELD_ON (if sent), the CLF shall start the 
initialization and anti-collision process as defined in ISO/lEC 14443-3 [6] using the parameters from the 
appropriate card RF gate registry for the present RF technology 



RQ9.85 



If The card RF gate sends EVT_CARD_ACTIVATED to the card application gate, it shall send it at the 
end of the activation sequence as defined ISO/lEC 14443-4 [7]. 



R09.86 



The card RF gate shall forward the C-APDUs from the external contactless reader to the card application 
gate using the EVT_SEND_DATA. 



R09.87 



If the CLF detects the end of the PICC deactivation sequence by the external contactless reader, the 
card RF gate shall send an EVT_CARD_DEACTIVATED 



RQ9.88 



In full power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall send EVT_FIELD_OFF to the card application gate. 



RQ9.89 



When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_OFF to the card 
application gate used during the transaction or to the open card application gate with the lowest Gip. 
In low power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall either send EVT_FIELD_OFF to the card application gate or power down the host 



RQ9.90 



RQ9.75 



When EVT_FIELD_ON Is sent by the host controller, it shall be sent within 2 ms after the detection of an 
RF field. 



R09.76 



In case of an underlying data link layer according to TS 102 613 [2], if SWP is in DEACTIVATED state, 
the CLF shall activate the interface instead of sending the EVT_FIELD_ON. 



RQ9.77 



When the host controller sends EVT_FIELD_ON, it shall not contain parameters. 



NOTE: Development of test cases for RQ9.83, R09.89, R09.75 and RQ9.77 is FFS. 



5.6.4.1 .2 Test case 1 : ISO/lEC 14443-3 Type A 

5.6.4.1.2.1 Test execution 

Run this test with the following parameters: 

• Full power mode. 

5.6.4.1.2.2 Initial conditions 

• A PlPEa is created and opened by the host with source Gid = '23' to the card RF gate of type A of HCUT. 

• Registries entries of card RF gate for RF technology type A shall be modified to execute the test. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type A protocol is powered off. 
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5.6.4.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HCUT 


While the field is off, the terminal is placed in the area where the field will 
be powered on. 




2 


PCD ^ HCUT 


Power on the field. 




3 


PCD ^ HCUT 


Transitions from POWER OFF to IDLE state. 




4 


HCUT^ HS 


If SWP was not in DEACTIVATED state when the field was powered on, 
the HCUT shall send EVT_FIELD_ON. 

If SWP was in the DEACTIVATED state when the field was powered on, 
the HCUT shall activate the interface instead of sending EVT FIELD ON. 


RQ9.82, 
R09.76 


5 


PCD ^ HCUT 
HCUT -^ PCD 


Perform initialization of RF ISO/IEC 14443-3 [6] Type A (with anti-collision 
and selection). 


R09.84 


6 


PCD ^ HCUT 


Send (RATS). 




7 


HCUT^ PCD 


Response (ATS). 




8 


PCD ^ HCUT 
HCUT^ PCD 


PPS procedure. 




9 


HCUT-^ HS 


The Terminal may send EVT CARD ACTIVATED. 


RQ9.85 


10 


PCD -> HCUT 


Send C-APDU. 




11 


HCUT-» HS 


Send EVT SEND DATA contains the received C-APDU on PIPEa. 


R09.86 


12 


HS -^ HCUT 


Send EVT SEND DATA contains the response on PIPEa. 




13 


HCUT -> PCD 


Send R-APDU. 




14 




If there is more data to exchange than repeat steps 9 to 12. 




15 


User -^ PCD 


Run the deactivation sequence. 




16 


PCD ^ HCUT 


Send DESELECT command. 




17 


HCUT^ HS 


Send EVT CARD DEACTIVATED. 


R09.87 


18 


User ^ HCUT 


The terminal is removed from the PCD field. 




19 


HCUT^ HS 


Send EVT_FIELD_OFF. 


RQ9.88, 
RO9.90 



5.6.4.1 .3 Test case 2: ISO/IEC 14443-3 Type B 

5.6.4.1.3.1 Test execution 
Run this test with the following parameters: 

• Full power mode. 

5.6.4.1.3.2 Initial conditions 

• A PIPEa is created and opened by the host with source Gid = '21' to the card RF gate of type B of HCUT. 

• Registries entries of card RF gate for RF technology type B shall be modified to execute the test. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type B protocol is powered off. 
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Step 


Direction 


Description 


RQ 


1 


User -» HCUT 


While the field is off, the terminal is placed in the area where the field will 
be powered on. 




2 


PCD ^ HCUT 


Power on the field. 




3 


PCD -» HCUT 


Transitions from POWER OFF to IDLE state. 




4 


HCUT^HS 


If SWP was not in DEACTIVATED state when the field was powered on, 
the HCUT shall send EVT_FIELD_ON. 

If SWP was in the DEACTIVATED state when the field was powered on, 
the HCUT shall activate the interface instead of sending EVT FIELD ON. 


R09.82, 
RQ9.76 


5 


PCD ^ HCUT 
HCUT^ PCD 


Perform initialization of RF ISO/IEC 14443-3 [6] Type B (with anti-collision 
and selection). 


RQ9.84 


6 


HCUT-^HS 


The Terminal may send EVT CARD ACTIVATED. 


RQ9.85 


7 


PCD ^ HCUT 


Send C-APDU. 




8 


HCUT^HS 


Send EVT SEND DATA contains the received C-APDU on PIPEa. 


RQ9.86 


9 


HS ^ HCUT 


Send EVT SEND DATA contains the response on PIPEa. 




10 


HCUT ^ PCD 


Send R-APDU. 




11 




If there is more data to exchange than repeat steps 9 to 1 2. 




12 


User -» PCD 


Run the deactivation sequence. 




13 


PCD ^ HCUT 


Send DESELECT command. 




14 


HCUT ^ HS 


Send EVT CARD DEACTIVATED. 


RQ9.87 


15 


User -» HCUT 


The terminal is removed from the PCD field. 




16 


HCUT^HS 


Send EVT_FIELD_OFF. 


R09.88, 
RQ9.90 



5.6.4.2 



Non ISO/IEC 14443-4 type A 



5.6.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.2. 



RQ9.91 



In full power mode, and if SWP is not in DEACTIVATED_state, when the CLF detects a RF field, the card 
RF gate shall send the event EVTFIELDON to the card application gate. 



RQ9.92 



When there are multiple open card RF gates the CLF shall send the EVT_FIELD_ON to the open card 
application gate with the lowest Gip. 



RQ9.93 



When the CLF detects a RF field, and after sending EVT_FIELD_ON (if sent), the CLF shall start the 
initialization and anti-collision process as defined in ISO/IEC 14443-3 [6] using the parameters from the 
card RF gate registry for the RF technology type A. 



R09.94 



Any other communications are done using the CLT mode as defined in TS 1 02 61 3 [2]. 



RQ9.95 



In full power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall send EVT_FIELD_OFF to the card application gate. 



R09.96 



When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_OFF to the card 
application gate used during the transaction or to the open card application gate with the lowest Gip. 
In low power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall either send EVT_FIELD_OFF to the card application gate or power down the host. 



RQ9.97 



R09.75 



When EVT_FIELD_ON is sent by the host controller, it shall be sent within 2 ms after the detection of an 
RF field. 



R09.76 



In case of an underlying data link layer according to TS 102 613 [2], if SWP is in DEACTIVATED state, 
the CLF shall activate the interface instead of sending the EVT_FIELD_ON. 



R09.77 



When the host controller sends EVT_FIELD_ON, it shall not contain parameters. 



NOTE: Development of test cases for above listed ROs is FFS. 



5.6.4.3 



Type B' RF technology 



5.6.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.3. 

NOTE: Defining conformance requirements is out of scope of the present document. 
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5.6.4.4 



Type F RF technology 



5.6.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.4. 



RQ9.98 



In full power mode, and if SWP is not in DEACTIVATED state, when the CLF detects a RF field, the card 
RF gate shall send the event EVTFIELDON to the card application gate. 



RQ9.99 



When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_ON to the open card 
application gate with the lowest Gip. 



RQ9.100 



In case SWP as defined in TS 102 613 [2] is used as a data link layer, when the CLF detects a RF field, 
and after sending EVT_FIELD_ON (if sent), the CLF shall start the initialization and anti-collision process 
performed using CLT as defined in TS 102 613 [2] for the RF technology ISO/IEC 18092 [4] 
212 kbps/424 kbps passive mode type F. 



RQ9.1024 



The card RF gate shall forward the ISO/IEC 18092 [4] 212 kbps/424 kbps frames from the external 
reader to the card application gate using the EVT_SEND_DATA with the structure specified in TS 102 
622 [1]. 



RQ9.103 



The host sending a response shall encapsulate the ISO/IEC 18092 [4] 212 kbps/424 kbps frames in an 
EVT_SEND_DATA event and shall send it to the card RF gate. 



RQ9.104 



In full power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall send EVT_FIELD_OFF to the card application gate.. 



RQ9.105 



When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_OFF to the card 
application gate used during the transaction or to the open card application gate with the lowest Gip. 



RQ9.106 



In low power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall either send EVT_FIELD_OFF to the card application gate or power down the host 



RQ9.107 



ISO/IEC 18092 [4] 212 kbps/424 kbps frames, except initialization command and response (command 
code '00' and '01'), shall be exchanged using the appropriate gate depending on the command code of 
the frame as described in TS 102 622 [1]. 



RQ9.108 



The command codes reserved for the NFCIP-1 protocol shall not be forwarded. 



RQ9.75 



When EVT_FIELD_ON is sent by the host controller, it shall be sent within 2 ms after the detection of an 
RF field. 



RQ9.76 



In case of an underlying data link layer according to TS 102 613 [2], if SWP is in DEACTIVATED state, 
the CLF shall activate the interface instead of sending the EVT_FIELD_ON. 



RQ9.77 



When the host controller sends EVT_FIELD_ON, it shall not contain parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.6.4.5 Update RF technology settings 
5.6.4.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.5. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.4.6 Identity check 



5.6.4.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.6. 



RO9.110 



If the lower identity check fails, the host controller shall not respond to the external contactless reader 
with any parameter from the card emulation registries related to the UICC host. 



NOTE: Development of test cases for above listed ROs is FFS. 
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5.7 



Contactless reader 



5.7.1 



Overview 



5.7.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.1. 



RQ10.1 



The host controller has one reader RF gate for each RF technology it supports. 



RQ10.2 



The CLF shall handle the RF layers of the communications as defined in ISO/IEC 14443-2 [5]. 
The anti-collision and activation as defined in ISO/IEC 14443-3 [6] shall be handled by the CLF 
under the control of the host. 



RQ10.3 



RQ10.4 



The RF protocol as defined in ISO/IEC 14443-4 [7] shall be handled by the CLF. 



RQ10.5 



The reader RF gate and reader application gate shall exchange APDUs defined in ISO/IEC 7816-4 
[8] over their pipe. 



NOTE: Development of test cases for above listed ROs is FFS. 



5.7.2 Reader RF gates 



5.7.2.1 Overview 

Reference: TS 102 622 [1], clause 10.2.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.2.2 Command 



5.7.2.2.1 



WR XCHG DATA 



5.7.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.2.1. 



RQ10.6 



If b5 of the CTR field of WR_XCHG_DATA is set to zero, application level time-out is deactivated. 



RQ10.7 



If b5 of the CTR field of WR_XCHG_DATA is set to one, then b4 to b1 is a time-out value which shall 
use to calculate the application level time-out with the formula specified in TS 102 622 [1]. 



RQ10.8 



When command WR_XCHG_DATA is successful, the host controller shall respond with ANY_OK 
with parameter which contains the data received and the RF error indicator. 



RQ10.9 



When command WR XCHG DATA is successful, the RF error indicator shall be '00' if no error. 



RQ10.10 



When command WR XCHG DATA is successful, the RF error indicator shall be '01' if error. 



NOTE: Development of test cases for above listed ROs is FFS. 
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5.7.2.3 



Registries 



5.7.2.3.1 



Type A reader RF gate 



5.7.2.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.3.1. 



RQ10.11 



Registry parameters whicli are in tlie range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



RQ10.12 



The registry is not persistent. 



RQ10.13 



The values are updated after each target activation. 



RQ10.14 



The CLF shall set a default value for UID REG of '08000000'. 



RQ10.15 



The CLF shall apply the access condition of RO for UID. 



RQ10.16 



The CLF shall use a default value for ATQA of '0000'. 



RQ10.17 



The CLF shall apply the access condition of RO for ATQA. 



RQ10.18 



The CLF shall use a default value for APPLICATION_DATA of an empty array. 



RQ10.19 



The CLF shall apply the access condition of RO for APPLICATION_DATA. 



RQ10.20 



The CLF shall use a default value for SAK of '00'. 



RQ10.21 



The CLF shall apply the access condition of RO for SAK. 



RQ10.22 



The CLF shall use a default value for FWI. SFGT of 'EE' 



RQ10.23 



The CLF shall apply the access condition of RO for FWI, SFGT. 



RQ10.24 



The CLF shall set a default value for DATARATE MAX of '00'. 



RQ10.25 



The CLF shall apply to the access condition of RW to DATARATE_MAX. 



RQ10.26 



The CLF shall accept valid values of DATARATE_MAX as defined in TS 102 622 [1]. 



RQ10.27 



The maximum supported divisor used over the RF interface shall be the minimum of the value as 
indicated in the registry and the maximum divisor implemented in the CLF. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.3.2 



Type B reader RF gate 



5.7.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.3.2. 



RQ10.28 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



RO10.29 



The registry is not persistent. 



RO10.30 



The values are updated after each target activation. 



RO10.31 



The CLF shall use a default value for PUPI of 'N0=0'. 



RO10.32 



The CLF shall apply the access condition of RO for PUPI. 



RQ10.33 



The CLF shall use a default value for APPLICATION DATA of 'N1=0'. 



RO10.34 



The CLF shall apply the access condition of RO for APPLICATION_DATA. 



RO10.35 



The CLF shall set a default value for AFI of '00'. 



RO10.36 



The CLF shall apply the access condition of RW to AFI. 



RO10.37 



The CLF shall use a default value for HIGHER LAYER RESPONSE of 'N2=0'. 



RO10.38 



The CLF shall apply the access condition of RO to HIGHER_LAYER_RESPONSE. 



RO10.39 



The CLF shall set a default value for HIGHER LAYER DATA of 'N3=0'. 



RO10.40 



The CLF shall apply the access condition of RW to HIGHER_LAYER_DATA. 



NOTE: Development of test cases for above listed ROs is FFS. 
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5.7.2.4 Events and subclauses 

5.7.2.4.1 Events 

5.7.2.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4. 



RQ10.41 



The reader RF gates shall support the EVT_READER_REQUESTED and EVT_END_OPERATION 
events. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.4.2 EVT_READER_REQUESTED 

5.7.2.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4.1. 



RQ10.42 



On receiving the EVT_READER_REOUESTED event, the CLF shall activate the RF polling (turn on the 
RF carrier). 



RO10.43 [The CLF shall accept EVT_READER_REQUESTED event on any open pipe of any reader RF gate. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.4.3 EVT_END_OPERATION 

5.7.2.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4.2. 



RO10.58 



Upon reception of the event EVT_END_OPERATION from a host the CLF controller shall turn the 
RF field OFF If the EVT_TARGET_DISCOVERED has been previously sent to that specific host 



NOTE: Development of test cases for RQ1 0.58 Is FFS. 



5.7.2.5 Responses 

5.7.2.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.5. 



RQ1 0.44 If command WR_XCHG_DATA Is successful, response shall be ANY_OK. 



RQ10.45 



If command WR_XCHG_DATA is rejected and /or not completed, response shall be ANY_E_OK. 



RQ10.46 



If Application level time-out occurred, the response shall be ANY_E_TIMEOUT. 



RQ10.47 |lf Target has returned an RF error the response shall be 'WR_RF_ERROR. 



NOTE: Development of test cases for above listed ROs Is FFS. 



5.7.3 Reacder application gates 
5.7.3.1 Overview 

Reference: TS 102 622 [1], clause 10.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.7.3.2 Command 

5.7.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.3.3 Registry 

5.7.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.3. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.3.4 Events and subclauses 

5.7.3.4.1 Events 

5.7.3.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.4. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.3.4.2 EVT_TARGET_DISCOVERED 

5.7.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.4.1. 



RQ10.48 



The existence of an RF target in the field of the activated RF technology shall be signalled to the 
reader application gate by EVT_TARGET_DISCOVERED event. 



RQ10.49 



If there is a single target in the reader field and the activation of the target is completed then the 
value of STATUS parameter of EVT_TARGET_DISCOVERED event shall be equal to '00'. 



RQ10.50 



If there are several targets in the field irrespective of the RF technology then the value of STATUS 
parameter of EVT_TARGET_DISCOVERED event shall be equal to '03'. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.4 Procedures 

5.7.4.1 Use of contactless reader application 

5.7.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.4.1. 



RQ10.51 



On receiving the EVT_READER_REQUESTED event, the CLF shall enable the RF polling. 



RO10.52 



Once RF polling is enabled, the CLF shall start the detecting of a target according to all reader RF 
gates of the host that have an open pipe. 



RQ10.53 



When a target has been detected and activated, the CLF shall notify the host via the event 
EVT TARGET DISCOVERD. 



RQ10.54 



If the several targets in the field then the procedure shall stop. 



RQ10.55 



When the CLF receives a response from the target to a forwarded C-APDU, the reader RF gate shall 
reply in sending back an R-APDU to the reader application gate. 
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RQ10.56 



If an application level time-out occurs before the CLF receives a response from the target, the CLF 
shall respond to the UICC with ANY_E_TIMEOUT. 



RQ10.57 



Once the CLF responds with ANY_E_TIMEOUT, it shall discard data received from the target 
thereafter. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8 Connectivity 



5.8.1 Overview 

Reference: TS 102 622 [1], clause 11.1. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2 Connectivity gate and subclauses 

5.8.2.1 Connectivity gate 

Reference: TS 102 622 [1], clause 11.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2.2 Commands 

5.8.2.2.1 PRO_HOST_REQUEST 

5.8.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.1.1. 



RQ11.1 



When the Terminal Host receives an PRO_HOST_REQUEST, it shall attempt to activate every host in 
the list of host identifiers during the Activation Duration. 



RQ11.2 



If every requested host has successfully been activated, the Terminal Host shall send an ANY_OK 
response with no parameters. 



R011.3 



If no requested host has been successfully activated, the Terminal Host shall send a response which is 
not ANY OK. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.2.3 Events and subclauses 

5.8.2.3.1 Events 

Reference: TS 102 622 [1], clause 11.2.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2.3.2 EVT_CONNECTIVITY 

5.8.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.1. 



RQ1 1 .4 



When the Terminal Host receives an EVT_CONNECTIVITY, it shall send a "HOI connectivity event" as 
defined in TS 102 223 [3]. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.8.2.3.3 Void 

Reference: TS 102 622 [1], clause 11.2.2.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2.3.4 EVT_OPERATION_ENDED 

5.8.2.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.3. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2.3.5 EVT_TRANSACTION 

5.8.2.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.4. 



RQ11.5 



When the Terminal Host receives an EVT_TRANSACTION, it shall attempt to launch an application 
associated to an NFC application in a UICC host identified by the AID. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.2.4 Registry 

5.8.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.3. 



RQ11.6 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.3 Connectivity application gate and subclauses 

5.8.3.1 Connectivity application gate 
5.8.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.3.2 Commands 

5.8.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.1. 
There are no conformance requirements for the Terminal Host for the referenced clause. 
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5.8.3.3 Events and subclauses 

5.8.3.3.1 Events 

5.8.3.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.3.3.2 EVT_STANDBY 

5.8.3.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.2.1. 



RQ1 1 .7 [When the terminal host send EVT_STANDBY, it shall not contain parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8.3.4 Registry 

5.8.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.3. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.4 Procedures 

5.8.4.1 Use of connectivity gate 

Reference: TS 102 622 [1], clause 11.4.1. 
There are no conformance requirements for the Terminal Host for the referenced clause. 



£75/ 



Release 8 65 ETSI TS 1 02 695-1 V8.0.0 (201 1 -06) 

Annex A (informative): 
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Annex B (informative): 

Core specification version information 

Unless otherwise specified, the versions of TS 102 622 [1] from which conformance requirements have been extracted 
are as follows: 



Release 


Latest version from which conformance requirements have been extracted 


7 


V7.8.0 


8 


V8.2.0 
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Annex C (informative): 
Change history 



The table below indicates all changes that have been incorporated into the present document since it was placed under 
change control. 



Change history 
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Plenary Doc 


CR 
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Cat 


Subject/Comment 
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7.0.0 


2010-07 
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F 
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F 
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SCP(10)0120 
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7.1.0 


7.2.0 
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SCP(1 1)0028 
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F 
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SCP(1 1)0029 


007 




F 


Numbering correction 


7.2.0 


7.3.0 


SCP(1 1)0030 


008 


- 


F 


Modify RF registries setting test cases to consider ihe 
procedure in TS 102 622 clause 9.4.5 


7.2.0 


7.3.0 


2011-03 


SCP #48 


SCP(11)0109 


009 


- 


F 


Specification of default of full power mode only for test 
execution 


7.2.0 


7.3.0 


SCPdDOIIO 


010 


- 


F 


ANY_OPEN_PIPE command is sent to tiie pipe already 
opened 


7.2.0 


7.3.0 


2011-03 


SCP #48 


scPdDom 


Oil 


- 


F 


Update thie requirements to version 7.8.0 of TS 102 622 


7.2.0 


7.3.0 


2011-03 


SCP #48 


SCP(11)0114 


014 


- 


F 


Correction of card emulation test cases to allow for SWP 
DEACTIVATED state and low power mode 


7.2.0 


7.3.0 


2011-03 


SCP #48 


SCP(11)0115 


015 




F 


Correction of state transition for ISO/I EC 14443-3 type B 


7.2.0 


7.3.0 


2011-03 


SCP #48 


SCP(11)0112 


012 


- 


F 


Creation of Rel-8 of TS 102 695-1 to cover Rel-8 conformance 
requirements of TS 102 622 


7.3.0 


8.0.0 
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